Date: Thu, 5 Apr 2001 13:01:12 -0500 From: Joe Thomas <joe_thomas@cnt.com> To: 'Alex Huppenthal' <alex@aspenworks.com>, Richard Hodges <rh@matriplex.com>, Harti Brandt <brandt@fokus.gmd.de> Cc: freebsd-atm@FreeBSD.ORG Subject: RE: ATM 4.3 and so on Message-ID: <67DB78CE91D7D41190A100508BFDF5E051EF14@esply03.cnt.com>
next in thread | raw e-mail | index | archive | help
Some thoughts on all the different HARP discussions: I'd be surprised if FORE is doing multi-VC rate control on the adapter UNLESS they're running a newer version of the microcode than what was available when HARP was developed. On transmit, there is a single transmit queue which acts as PDU fifo. Each PDU in has its own rate info (transmit M cells followed by N idle cells) and each PDU was transmitted to completion before the next PDU was examined. This doesn't allow the adapter to intermix cells from different VCs in the output stream. The microcode certainly was not able to do policing on inbound VCs so this again would have to be something new in the microcode. If indeed there is newer microcode, the driver would almost certainly have to be re-written in order to take advantage of any new features. [It may be that in order to implement rate control they simply added the ability for the microcode to examine the entire transmit queue vs. only the head and therefore there wouldn't be any changes to the driver (modulo that HARP doesn't have any real QoS support.)] As to the fragmentation problem, this ought to be fairly simple to see who's doing the fragmentation. I would start by looking at the PDU's that are handed off to ipatm_output(). Look in src/sys/netatm/ipatm/ipatm_output.c and examine the pdus (KBuffer *m) in the mbuf chain. You could also look at them as they go into the driver by examining src/sys/dev/hfa/fore_output.c. I'd be very surprised if HARP was doing anything since it doesn't do IP fragmenting anywhere. If you have "options DIAGNOSTIC" in your config, you can use gdb to set 'atm_dev_print' and 'atm_print_data' to non-zero and have HARP dump the mbuf info. Otherwise you'll have to rebuild your kernel and either add you're own code and/or set DIAGNOSTICS. [At one time, someone had some bpf hooks to grab IP traffic. I haven't kept up with BPF and it's been so long ago I'm not sure I could find it anymore. IP should be trivial to add - it's the ATM bpf support that's hard(er).] Hope this is helpful to someone... Joe Thomas -----Original Message----- From: Alex Huppenthal [mailto:alex@aspenworks.com] Sent: Thursday, April 05, 2001 12:21 PM To: Richard Hodges; Harti Brandt Cc: freebsd-atm@FreeBSD.ORG Subject: Re: ATM 4.3 and so on Fore support is actually very good. They have the linux code drivers, documentation on various parts of the PCA 200 for driver developers.. I am now somewhat experienced with Windozes 2K Advanced server support for the PCA200. It appears to do policing and pacing (ingress and egress respectively), have support for muiltple PVCs, ATM/ARP server support, and an interesting blob of IP related options, such as PPP over ATM, ELAN support, etc. etc. It's kinda flaky, in my opinion. It took more than a week to get it operating relatively smoothly. It still loses connection to the card, causes infinite boot times, and login time, periodically.. It does not however, fragment PDUs in a way which results in a 'fragment attack' PDU discard at the Xedia/Lucent router CBQ layer. For now, my network is running ATM via W2K to a couple of Ethernet ports. Not wildly speedy, but it's just a dual pentium pro with 1 meg of cache a 256M of memory, what seems to be about 1/4 the horsepower required to lift the 2K OS off the ground.. ;-) I'm ready to throw a couple hundred bucks into the puzzle of why our FreeBSD 4.3 OS/stack/driver creates this frags. I have cell pacing sorta fixed by causing our OC-3 circuit to pace cells outbound - it has a 32MB buffer, so dummynet should throttle the overall rate out, and the OC3 lucent card can pace each cell group out. -Alex At 04:34 AM 04/05/2001, you wrote: >It looks like a new version of the drivers are on the way. More features, >better compatibility, and supported since they are just being written. The >downside is that they won't be ready until mid-May. > >A member of the tech team indicated they he was unable to build the -current >version of BSD with the ATM HARP stack, which is what we use. I'm continuing >the investigation. o ----- Original Message ----- From: "Richard Hodges" <rh@matriplex.com> To: "Harti Brandt" <brandt@fokus.gmd.de> Cc: "Alex Huppenthal" <alex@aspenworks.com>; <freebsd-atm@FreeBSD.ORG> Sent: Thursday, April 05, 2001 10:43 AM Subject: Re: ATM 4.3 and so on > On Thu, 5 Apr 2001, Harti Brandt wrote: > > > On Wed, 4 Apr 2001, Richard Hodges wrote: > > > > RH>The third would be suitable for filling a DS3 (96000 cells/s), and the > > RH>fourth could carry 10 mb/s of user data. Keep in mind that this is per > > RH>VC, so if you have many going at once, you may still exceed your cell > > RH>rate. I believe that the Fore card expects this rate info in network > > RH>byte order, but if not, just remove the "htonl()" from the macro. There > > RH>are many more possible values; let me know if you want the rest. > > RH> > > RH>And I haven't tested this myself, so if you give it a try, please let > > RH>us all know how it works :-) > > > For what I know, this works only for a single VC. As soon as you try to > > shape more than one VC, things go wrong. Three years ago a Fore engineer > > told me, that they are going tu support shaping of up to 32 VC's 'in the > > Windows driver'... :-( > > Well, that ^h^h^h^h^h is not good. From the rate control values, it > did look like some kind of burst/skip system. Both values add up to > 255. Could it be that the rate is actually the entire interface rate > while that PDU is sent? That would make it complicated to handle > multiple VCs, but not impossible. Unfortunately, the cell spacing > would probably still be a problem. > > Yuck. > > I think I will stick with the ForeLE (IDT) cards. > > All the best, > > -Richard > > ------------------------------------------- > Richard Hodges | Matriplex, inc. > Product Manager | 769 Basque Way > rh@matriplex.com | Carson City, NV 89706 > 775-886-6477 | www.matriplex.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-atm" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-atm" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?67DB78CE91D7D41190A100508BFDF5E051EF14>