Date: Thu, 5 Apr 2001 11:21:06 -0600 From: "Alex Huppenthal" <alex@aspenworks.com> To: "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: <002101c0bdf4$cfd226e0$1800a8c0@d7k> References: <Pine.BSF.4.10.10104050937080.45890-100000@mail.matriplex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002101c0bdf4$cfd226e0$1800a8c0>