Re: dc0 wierdness with Compex Freedomline
> <<[EMAIL PROTECTED]> said: > > >> The maximum for full-duplex is utterly irrelevant, since the bounds on > >> performance for half-duplex Ethernet networks come from CSMA/CD. > > > I will say it one last time, duplex falls out of the equations when you > > solve for ``maximal''. > > Nonsense. Either stop saying that or put up the formula's like I did that show that duplex enters into the L2 maximal data rate. > > It has 0 meaning in the numbers used. Go read > > my analysis and tell me why I can't pump 12MB/sec on 100BaseTX, > > By no means -- you certainly can do that, if you have only one station > sending at a time. Of course, a monologue is by definition not useful > communication. You have a very twisted definition of communication. > > You keep throwing P(coll) in, P(coll) only occurs if your upper layer is > > causing P(coll) by doing things like ack packets. > > I'd certainly like to see a demonstration of your network using ESP > for reliability. Have you ever calculated the BER of a controlled CSMA/CD network? It is something like 10^-9. I could show you 4 working implementations of this, but I would have to call the boys in grey coats afterwards. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
< said: >> The maximum for full-duplex is utterly irrelevant, since the bounds on >> performance for half-duplex Ethernet networks come from CSMA/CD. > I will say it one last time, duplex falls out of the equations when you > solve for ``maximal''. Nonsense. > It has 0 meaning in the numbers used. Go read > my analysis and tell me why I can't pump 12MB/sec on 100BaseTX, By no means -- you certainly can do that, if you have only one station sending at a time. Of course, a monologue is by definition not useful communication. > You keep throwing P(coll) in, P(coll) only occurs if your upper layer is > causing P(coll) by doing things like ack packets. I'd certainly like to see a demonstration of your network using ESP for reliability. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
> <<[EMAIL PROTECTED]> said: > > >> I answered SPECIFICALLY about half-duplex. > > > The duplex does not in any way effect the maximal link layer transmission > > data rate. You seem to keep forgetting the maximal part... > > The maximum for full-duplex is utterly irrelevant, since the bounds on > performance for half-duplex Ethernet networks come from CSMA/CD. I will say it one last time, duplex falls out of the equations when you solve for ``maximal''. It has 0 meaning in the numbers used. Go read my analysis and tell me why I can't pump 12MB/sec on 100BaseTX, tell me that my 15 years of doing 97.5% of data clock on ethernet just doesn't happen. Then tell me why it can't happen, show me numbers and equations and I'll show you how you forget the keyword maximal and keep jumping over to something less than maximal as your not narrowing the scope of what it is your measureing/calculating. You keep throwing P(coll) in, P(coll) only occurs if your upper layer is causing P(coll) by doing things like ack packets. CSMA/CD does not define this. It defines the exact things I have used in the calculations to derive the number. There is no other number and no other formula to apply when solving for maximal. I can back up my numbers with lab data, 15 years of lab data. The only thing that effects maximal data transfer on a CSMA/CD network is IFG, MTU (not the upper layer MTU the layer 2 frame MTU) and layer 2 overhead bytes as clearly formulated in my post (preamble, Start of Frame, Source Address, Destination Address, type and CRC). The IFG is the multi-access window, if no one else accesses the media during the IFG (technically a violation of spec) one is free to start your next frame of transmission. If 2 nodes attempt to access the media at end of IFG you have P(coll), solving for maximal says that this never occurs to get maximal. THAT IS THE END OF THE STORY AS IT WORKS IN THE REAL WORLD DAY AFTER DAY IN 4 DESIGNS I HAVE DONE FOR PEOPLE. The only bloody ack that can cause a collission in our l3 design occurs after the whole of the data transfer, thus they don't effect our 1 way data transfer rate except by 64 bytes in Megabytes of data which shows up out in the 4th or 5th digit and is _NOT_ the maximal link layer data rate (the link layer is till doing 97.5% of data clock, the data is just going the other way :-)). -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
< said: >> I answered SPECIFICALLY about half-duplex. > The duplex does not in any way effect the maximal link layer transmission > data rate. You seem to keep forgetting the maximal part... The maximum for full-duplex is utterly irrelevant, since the bounds on performance for half-duplex Ethernet networks come from CSMA/CD. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
> <<[EMAIL PROTECTED]> said: > > > I specifically excluded P(coll) by stating point to point or effectively > > point to point via switching. > > Rod, please bother to READ what people write before spewing nonsense. I did read it, and did not spew nonsense. P(coll) is non-sense when talking about maximal. > The original question asked SPECIFICALLY about half-duplex. It also asked about ``maximal'', I solved the equations for maximal, to achive maximal P(coll)=0. > I answered SPECIFICALLY about half-duplex. The duplex does not in any way effect the maximal link layer transmission data rate. You seem to keep forgetting the maximal part... -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
< said: > I specifically excluded P(coll) by stating point to point or effectively > point to point via switching. Rod, please bother to READ what people write before spewing nonsense. The original question asked SPECIFICALLY about half-duplex. I answered SPECIFICALLY about half-duplex. End Of Story. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
> <<[EMAIL PROTECTED]> said: > > >> [I wrote:] > >> quite right. In a CSMA/CD medium access protocol, like that used by > >> Ethernet, the actual capacity of the link is always(*) somewhat less than > >> 100%; the exact value depends on the precise parameters of the > >> transmissions at both ends.(**) > > >> (*)In non-trivial conditions; i.e., when actual work is being done. > >> (**)I've heard numbers between 70% and 95%. > > > And the major set of parameters that effect the higher side of this > > number are MTU(Maximum Transmission Unit) and IFG (Interframe Gap) > > and the protocol overhead of what ever proto you are using. > > Nope. Those two values are defined by the protocol, and are not > parameters at all. (It's only a parameter if it could conceivably be > varied in an experiment.) Don't tell the guys at PARC, Intel, DEC or TRW these are not parameters, the MTU as defined by the ethernet specification has a minimal and maximal value. That pretty much makes it a parameter. Also the 1518 bytes is the in-spec maximal but many chips, even the old 82586, could be programmed to do 4K or larger frames. (TRW takes advantage of the 82586's ability to do 16KByte frames for pumping huge images around very effecently on ethernet. Given that I have worked on real world systems that modify the MTU to reach a desired goal I can state without a doubt that MTU is a paramter, as I have changed not just in experiments or on paper, but in the real world with 1000's of systems deployed using the tweaked value, including having to hack out the jabber circuits in hubs to deal with the frame size.) > The relevant parameters are the > transmission schedules of the end stations, which are of course > dynamic in most real-world applications, but not necessarily so. Those parameters mean nothing when caclulating the Data Link layer maximal transmission rate possible. If they use them then you are calculation something else, like the application maximal transmission rate. > These can be boiled down into a single number P(coll), which is the > probability that two stations will cause a collision by transmitting > at precisely the same time. Although this seems unlikely, certain > kinds of network protocols can unintentionally synchronize > end-stations to the extent of causing pessimal behavior. I specifically excluded P(coll) by stating point to point or effectively point to point via switching. P(coll) is 0 in this situation, again going to my note of keyword ``maximal''. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
> On Fri, Feb 25, 2000 at 01:25:59AM -0800, Rodney W. Grimes wrote: > > > > There was a patch of DC21143 chips it seems that has a very strange > > thermal problem. Can you tell me what your hub link lite is doing > > when you see this major slow down? > > Nope ... as this machine is connected directly to the UTP-socket in the > wall .. which is connected to an HP-switch which is hidden in a locked 19" > rackmount (without a looking glass). :-(. Then do the next best thing, look at the lights on the back of the card (another reason I like the KNE100TX, it has them, not all DC21x4x cards do.) > > If you abort all traffic does the link light keep blinking wildly? > > > > If you power the machine down for an hour or so and let everything cool > > down nice and cool does it seem to work for a longer period of time before > > the speed drops? > > As far as i can remember leaving the system powered down for a longer > period of time indeed seems to make the connection work properly again for > a (little) while ... at least a short power-down to give everything a > chance to reinitialize hardly ever seems to be working. Sounds like we might be on the right track. > > If you see any of these symptoms call Kingston tech support, describe > > the problem to them, ask them for an RMA number :-) > > > > What is the date code on your DC21143 chip (I think I am recalling that > > you said you had a KNE100TX, and I am assuming you do, and that it is > > of new enough vintage to be the 21143 chip, and that it might be in this > > same range of chips we had problems with (33% of 4 lots of 20 cards would > > go to la la land within 1 to 2 hours of being placed into burn in). > > Well .. it's not my own system which is having these problems but of a > friend of mine ... I'll check this information with him today and have a > talk with the place that sold us this card. > > Thank you very much for providing this insight ... Your welcome. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
< said: >> [I wrote:] >> quite right. In a CSMA/CD medium access protocol, like that used by >> Ethernet, the actual capacity of the link is always(*) somewhat less than >> 100%; the exact value depends on the precise parameters of the >> transmissions at both ends.(**) >> (*)In non-trivial conditions; i.e., when actual work is being done. >> (**)I've heard numbers between 70% and 95%. > And the major set of parameters that effect the higher side of this > number are MTU(Maximum Transmission Unit) and IFG (Interframe Gap) > and the protocol overhead of what ever proto you are using. Nope. Those two values are defined by the protocol, and are not parameters at all. (It's only a parameter if it could conceivably be varied in an experiment.) The relevant parameters are the transmission schedules of the end stations, which are of course dynamic in most real-world applications, but not necessarily so. These can be boiled down into a single number P(coll), which is the probability that two stations will cause a collision by transmitting at precisely the same time. Although this seems unlikely, certain kinds of network protocols can unintentionally synchronize end-stations to the extent of causing pessimal behavior. Back in the mists of ancient time, this was considered one of the major arguments against CSMA/CD protocols and for token-passing protocols, and many academic papers were written about it. How horrifying, that your dearly-bought 10-Mbit/s (or even 3-Mbit/s) Ethernet channel could be wasting 30% of its capacity on collisions! Nowadays, we recognize that the sort of protocols which show pathological behavior are a bad idea for lots of reasons, and the normal operation of TCP and IP over an Ethernet channel results in significantly better than worst-case behavior. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
At 1:13 AM -0800 2000/2/25, Rodney W. Grimes wrote: > So infact the Layer 2 maximal data rate of 100BaseTX is 97.5929Mb/s or > 12.1912MB/s. I'll leave the Layer 3 to 7 calculation up to the reader, > as I am a hardware geek and I showed you how to do the calculations > at the hardwire layer, you software geeks can go figure out the > overhead for the software layers :-). I always enjoy seeing detailed discussions of things like this. I may not ever need this information, and I probably won't remember it if I do, but I will probably remember that I read something about it before and can go back and re-read what you just posted. Thanks! -- These are my opinions and should not be taken as official Skynet policy _ |o| Brad Knowles, <[EMAIL PROTECTED]> Belgacom Skynet NV/SA |o| |o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.13.11/726.93.11 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
On Fri, Feb 25, 2000 at 01:25:59AM -0800, Rodney W. Grimes wrote: > > There was a patch of DC21143 chips it seems that has a very strange > thermal problem. Can you tell me what your hub link lite is doing > when you see this major slow down? Nope ... as this machine is connected directly to the UTP-socket in the wall .. which is connected to an HP-switch which is hidden in a locked 19" rackmount (without a looking glass). > If you abort all traffic does the link light keep blinking wildly? > > If you power the machine down for an hour or so and let everything cool > down nice and cool does it seem to work for a longer period of time before > the speed drops? As far as i can remember leaving the system powered down for a longer period of time indeed seems to make the connection work properly again for a (little) while ... at least a short power-down to give everything a chance to reinitialize hardly ever seems to be working. > If you see any of these symptoms call Kingston tech support, describe > the problem to them, ask them for an RMA number :-) > > What is the date code on your DC21143 chip (I think I am recalling that > you said you had a KNE100TX, and I am assuming you do, and that it is > of new enough vintage to be the 21143 chip, and that it might be in this > same range of chips we had problems with (33% of 4 lots of 20 cards would > go to la la land within 1 to 2 hours of being placed into burn in). Well .. it's not my own system which is having these problems but of a friend of mine ... I'll check this information with him today and have a talk with the place that sold us this card. Thank you very much for providing this insight ... -- Pascal Hofstee < daeron @ shadowmere . student . utwente . nl > Managers know it must be good because the programmers hate it so much. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
> On Thu, Feb 24, 2000 at 02:07:40PM -0500, Garrett Wollman wrote: > > < said: > > Assuming you mean ``100BASE-T (half duplex)'' here... This is not > > quite right. In a CSMA/CD medium access protocol, like that used by > > Ethernet, the actual capacity of the link is always(*) somewhat less than > > 100%; the exact value depends on the precise parameters of the > > transmissions at both ends.(**) > > Ok ... we all know what exactly should be theoretical maximum and all ... > but that wasn't exactly my question ... I have having weird problems with > the network performance permanently dropping to below 100 kB/s (while still > in 100 Mbps/FDX). Is there anybody that could give a plausible explanation > for this break-down ? There was a patch of DC21143 chips it seems that has a very strange thermal problem. Can you tell me what your hub link lite is doing when you see this major slow down? If you abort all traffic does the link light keep blinking wildly? If you power the machine down for an hour or so and let everything cool down nice and cool does it seem to work for a longer period of time before the speed drops? If you see any of these symptoms call Kingston tech support, describe the problem to them, ask them for an RMA number :-) What is the date code on your DC21143 chip (I think I am recalling that you said you had a KNE100TX, and I am assuming you do, and that it is of new enough vintage to be the 21143 chip, and that it might be in this same range of chips we had problems with (33% of 4 lots of 20 cards would go to la la land within 1 to 2 hours of being placed into burn in). The problem seems to have started shortly after Intel took over production of the chips from DEC. I have not seen the problem in the last 6 lots of product. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
> < said: > > > > The theoretical maximum for 100BaseT-FDX (which is 200Mbps) is 25MB/s > > (megabytes per second), 100BaseT-TX is 12MB/s [FYI: Mbps->MB/s you divide > > by 8] I realize my punctuation may be off, but there you are. > > Assuming you mean ``100BASE-T (half duplex)'' here... This is not Just to put a final nit pick on this... 100BASE-T is not defined by the standards. 100baseTX, 100baseFX, and 100baseT4 are. > quite right. In a CSMA/CD medium access protocol, like that used by > Ethernet, the actual capacity of the link is always(*) somewhat less than > 100%; the exact value depends on the precise parameters of the > transmissions at both ends.(**) > > -GAWollman > > (*)In non-trivial conditions; i.e., when actual work is being done. > > (**)I've heard numbers between 70% and 95%. And the major set of parameters that effect the higher side of this number are MTU(Maximum Transmission Unit) and IFG (Interframe Gap) and the protocol overhead of what ever proto you are using. For those really interested in the nuts and bolts of the calculations for this I refer you to ``Switched, Fast and Gigabit Ethernet Third Edition'' Robert Bryer & Sean Riley, ISBN 1-57870-073-6 chapter 7, ''Bandwidth: How Much Is Enough?''. Also chapter 2 in the same book for some of the data used below and for a more indepth explination of what all these things are, for that matter, 802.* :-) Some interesting numbers: (In a format that might help some people understand where the magic numbers 1500, 1518 and 1538 come from in ethernet documentation (though few folks but ethernet framer geeks would ever deal with the 1538 number :-)). Layer 2 maximal data rate: (ie, raw ethenet packets, no protocol) data / ( IFG + ( Preamble + SFD ) + DA + SA + type + data + CRC ) = 1500 / ( 12 + ( 7+ 1 ) + 6 + 6 + 2+ 1500 + 4 ) = 97.53% 1500 / ( 12 + ( 8 ) + 1518) = 97.53% 1500 / ( 1538 ) = 97.53% So infact the Layer 2 maximal data rate of 100BaseTX is 97.5929Mb/s or 12.1912MB/s. I'll leave the Layer 3 to 7 calculation up to the reader, as I am a hardware geek and I showed you how to do the calculations at the hardwire layer, you software geeks can go figure out the overhead for the software layers :-). Please note that ``maximal'' is a key word in the above discussion, so please don't tell me that not all frames are 1500 bytes of data, because if they are not 1500 bytes of data you didn't solve the problem for the maximal. The first hardware that I know of that was ever capable of doing the 95.53% at the link layer was the i82586 by Intel on 10base, and you had to lock the sucker up in continues ring search mode with a good shared memory access mechanism to make it hit that. You needed very large chunks of shared memory (MB's) to sustain a very long burst of traffic at wire speed. You can not use ethernet in a shared mode and achive these numbers (point to point or effectivly point to point via switching only). Anyone quoteing ethernet or any other MAC layer data rates without atleast as much detail as above is practicing abuse of statistics and not presenting hard factual data which should be treated as such. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
> No, it is not. It is 100Mbps upstream and 100Mbps downstream. You cannot get > 200Mbps in one direction. FDX (Full Duplex) simply means that the RX and TX > cables are used simultaneous. Due to the small ethernet frame size, it is > next to impossible to get the full speed for data transmission. FreeBSD has been able to do that (full speed) for several years now. I measured this myself way back in June 1997, between a P-133 and a PPro-200. You can do much better with current hardware. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
> Ok ... we all know what exactly should be theoretical maximum and all ... > but that wasn't exactly my question ... I have having weird problems with > the network performance permanently dropping to below 100 kB/s (while still > in 100 Mbps/FDX). Is there anybody that could give a plausible explanation > for this break-down ? Most likely you have a duplex mismatch, ie. one end full duplex, the other half duplex. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
On Thu, Feb 24, 2000 at 02:07:40PM -0500, Garrett Wollman wrote: > < said: > Assuming you mean ``100BASE-T (half duplex)'' here... This is not > quite right. In a CSMA/CD medium access protocol, like that used by > Ethernet, the actual capacity of the link is always(*) somewhat less than > 100%; the exact value depends on the precise parameters of the > transmissions at both ends.(**) Ok ... we all know what exactly should be theoretical maximum and all ... but that wasn't exactly my question ... I have having weird problems with the network performance permanently dropping to below 100 kB/s (while still in 100 Mbps/FDX). Is there anybody that could give a plausible explanation for this break-down ? -- Pascal Hofstee < daeron @ shadowmere . student . utwente . nl > Managers know it must be good because the programmers hate it so much. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
On Thu, Feb 24, 2000 at 07:48:35PM +0100, Dieter Rothacker wrote: > No, it is not. It is 100Mbps upstream and 100Mbps downstream. You cannot get > 200Mbps in one direction. FDX (Full Duplex) simply means that the RX and TX > cables are used simultaneous. Due to the small ethernet frame size, it is > next to impossible to get the full speed for data transmission. You're right, I stand corrected. FDX is 100Mbps wide, but bi-directional, so it's only 12MB/s maximum theoretical speed (not including protocol overhead and what-not) .. I was basing the original opinion posted on assumed total bandwidth (100Mbps both ways) which is incorrect. I apologize for my ignorance :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
< said: > The theoretical maximum for 100BaseT-FDX (which is 200Mbps) is 25MB/s > (megabytes per second), 100BaseT-TX is 12MB/s [FYI: Mbps->MB/s you divide > by 8] I realize my punctuation may be off, but there you are. Assuming you mean ``100BASE-T (half duplex)'' here... This is not quite right. In a CSMA/CD medium access protocol, like that used by Ethernet, the actual capacity of the link is always(*) somewhat less than 100%; the exact value depends on the precise parameters of the transmissions at both ends.(**) -GAWollman (*)In non-trivial conditions; i.e., when actual work is being done. (**)I've heard numbers between 70% and 95%. -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
On Thu, 24 Feb 2000 10:21:31 -0700, Chris Wasser wrote: >> Downloading an 128 MB-file from the network to /dev/null results in speeds >> like 9.8 MB/s (close to the theoretical maximum for a 100 Mbps network) > >The theoretical maximum for 100BaseT-FDX (which is 200Mbps) is 25MB/s >(megabytes per second), 100BaseT-TX is 12MB/s [FYI: Mbps->MB/s you divide >by 8] I realize my punctuation may be off, but there you are. No, it is not. It is 100Mbps upstream and 100Mbps downstream. You cannot get 200Mbps in one direction. FDX (Full Duplex) simply means that the RX and TX cables are used simultaneous. Due to the small ethernet frame size, it is next to impossible to get the full speed for data transmission. -- Dieter Rothacker To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
Don't forget protocol overhead. Chris Wasser wrote: > On Thu, Feb 24, 2000 at 12:04:38PM +0100, Pascal Hofstee wrote: > > media: autoselect (100baseTX ) > > > > Downloading an 128 MB-file from the network to /dev/null results in speeds > > like 9.8 MB/s (close to the theoretical maximum for a 100 Mbps network) > > The theoretical maximum for 100BaseT-FDX (which is 200Mbps) is 25MB/s > (megabytes per second), 100BaseT-TX is 12MB/s [FYI: Mbps->MB/s you divide > by 8] I realize my punctuation may be off, but there you are. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- PETER SCHWENK| UNIX System Administrator Department of Mathematical Sciences | University of Delaware [EMAIL PROTECTED]| (302)831-0437 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc0 wierdness with Compex Freedomline
On Thu, Feb 24, 2000 at 12:04:38PM +0100, Pascal Hofstee wrote: > media: autoselect (100baseTX ) > > Downloading an 128 MB-file from the network to /dev/null results in speeds > like 9.8 MB/s (close to the theoretical maximum for a 100 Mbps network) The theoretical maximum for 100BaseT-FDX (which is 200Mbps) is 25MB/s (megabytes per second), 100BaseT-TX is 12MB/s [FYI: Mbps->MB/s you divide by 8] I realize my punctuation may be off, but there you are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
dc0 wierdness with Compex Freedomline
Hello, I am experiencing some weird problems with the dc-driver for a specific ethernet-card ... the Compex Freedomline (10/100 Mbps). The card perfectly seems to autodetect the mode it should operate on and seems to indeed be working just fine just after the system has booted up. --[dmesg]--- dc0: port 0xb400-0xb47f mem 0xdd00-0xdd7f irq 11 at device 12.0 on pci0 dc0: Ethernet address: 00:80:48:e7:1a:8e miibus0: on dc0 dcphy0: on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto --[ifconfig]-- sl0: flags=c010 mtu 552 ppp0: flags=8010 mtu 1500 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff00 dc0: flags=8843 mtu 1500 inet 130.89.226.126 netmask 0x broadcast 130.89.255.255 ether 00:80:48:e7:1a:8e media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX none Downloading an 128 MB-file from the network to /dev/null results in speeds like 9.8 MB/s (close to the theoretical maximum for a 100 Mbps network) After a (little) while though network performance almost comes to a halt somewhere around 6 to 32 kB/s ... and never seems to "recover" again. --[uname]-- FreeBSD cam043216.student.utwente.nl 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Sat Feb 19 10:29:30 CET 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/DINGO i386 Anybody that could help me out trying to figure out why the card seems to break down like this ? -- Pascal Hofstee < daeron @ shadowmere . student . utwente . nl > Managers know it must be good because the programmers hate it so much. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
