Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: Heiroglyph on January 04, 2015, 06:42:19 AM
-
My system is an A4000 060/50/96MB, Mediator, Realtek 8139D and Radeon 128MB with 93MB used for fast RAM.
I'm running Roadshow for TCP. (I love it so far, well worth the price)
When I use AmiFTP to transfer files from my server (local server, gigabit, fast RAID and CPU) I only get about 780,000 cps whether I transfer to RAM: or a hard drive.
I've done a few of the Roadshow tweaks mentioned in another thread, is there anything Mediator specific that can be adjusted?
Is this normal? It seems really low for 100Mb.
-
Well, 100 Mb/s (megabits per second) equals 12.5 MB/s (12.5 megabytes/sec) with no overhead (error checking,mostly), but only about 50% can be used, so 50 Mbits/s data transfer =~ 4.7 to 6.0 MB/s (max). Now you are getting < 1 MB/s, so there is a bottleneck. The Buster chip limits the estimated 150 MB/s Zorro 3 speed to about 13.5 MB/s and the limit on Amiga to PCI card in a Mediator seems a max of 12 MB/s. Jens of icomp.de says, "Roadshow is a commercial product still available today, but since it does not reach the speeds that AmiTCP/Genesis can reach" but I can't find results of his testing. He does state elsewhere, "Transfer rates of over 1600kBytes/s [1.6 MB/s] have been measured with the X-Surf-100. Please note that the classic Amiga architecture and the current TCP/IP stacks for the Amiga don't allow saturating a 100MBit Ethernet link. Performance in your system may be slower due to CPU performance and programs running in multitasking."
I think that somewhere in there is your answer.
-
I found something of use on eab, a netio benchmark from matthey using an 060/75 and Mediator.
NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 2033.78 KByte/s Tx, 321.98 KByte/s Rx.
Packet size 2k bytes: 405.09 KByte/s Tx, 574.51 KByte/s Rx.
Packet size 4k bytes: 723.33 KByte/s Tx, 766.37 KByte/s Rx.
Packet size 8k bytes: 1320.06 KByte/s Tx, 876.72 KByte/s Rx.
Packet size 16k bytes: 1618.56 KByte/s Tx, 1356.06 KByte/s Rx.
Packet size 32k bytes: 1644.96 KByte/s Tx, 1663.01 KByte/s Rx.
Done.
I'm not sure my setup will actually complete the test, it seems to stop, but not lock up.
With the tweaks given here http://www.amiga.org/forums/showpost.php?p=751014&postcount=48 it just stops after giving Packet size 1k bytes: 923.34 KByte/s Tx and never seems to finish Rx.
Removing all the tweaks gives:
1K bytes: 901.88 KByte/s Tx, 946.49 KByte/s Rx.
2K bytes: 1067.00 KByte/s Tx,
Then it just stops again.
Edit: it seems that after running netio, Roadshow is no longer functional. GetNetStatus looks good, but not even ping will complete, it just sits there with no crash.
-
I uninstalled Roadshow and installed Genesis (yuk)
It will now complete the test and has somewhat better performance, but still crap. It also locks the machine when I go offline :( The machine was incredibly stable prior to this.
1k: 1375 tx, 184 rx
2k 147 tx, 272 rx
4k 275 tx, 276 rx
8k 510 tx, 531 rx
16k 946 tx, 835 rx
32k 1004 tx, 868 rx
And on FTP I get 1,138,000 cps.
I've tried two different realtek cards with no change and two different versions of the FastEthernet.device
-
Changing the 10/100 card for an 8029 and still using Genesis gives me:
1k 843 tx, 446 rx
2k 231 tx, 427 rx
4k 400 tx, 654 rx
8k 551 tx, 651 rx
16k 599 tx, 739 rx
32k 703 tx, 714 rx
FTP gives 982,000 cps.
In many cases, that's actually an improvement.
WTF?
-
The X-surf 100 has tweaks for AmiTCP in the SANA2 ENV file and AmiTCP version 4 is available from Amigakit as Easynet Pro. As Jens posts commonly on EAB, I'd search there for the tweaks.
I WTF'd your findings in the above post too.
-
Hi Heiroglyph,
I'm the Matt Hey with the Mediator+Genesis results you found on EAB. I do have a very fast 68060 and memory so my results are probably not obtainable by most 68060 owners. There seems to be some bottleneck on my system also as my results vary between fast and slow. I have no connection or stability problems though.
I don't know what is causing your problems so I will give you my working setup.
3000T, CSMK3 68060@75MHz, AmigaOS 3.9 with fixes
My ENVARC:Mediator variables:
FastEthernet 0
MMU YES
VoodooInt YES (may be different depending on gfx board)
VoodooMem 30 (I have a Voodoo 4 so this will likely be different for you)
Library and device versions:
Libs:68060.library 43.4 Mu/MMU.lib from ThoR
Devs:Networks/FastEthernet.device 1.25
Libs:pci.library 9.7
Libs:Picasso96/Voodoo.card 4.34
Note that some of my versions are older because of new bugs.
I uninstalled Roadshow and installed Genesis (yuk)
Genesis isn't that bad is it? It has a GUI with a choice of ClassAct or MUI and it is fast.
My Genesis prefs:
(Interface tab)
Name: FastEthernet
Comment:
IP Address: 192.168.0.100 (static)
Destination: (dynamic)
Gateway: 192.168.0.1 (static)
NetMask: 255.255.255.0 (specify)
MTU: 1500
Params:
-
Thanks for chiming in.
Hi Heiroglyph,
My ENVARC:Mediator variables:
FastEthernet 0
MMU YES
VoodooInt YES (may be different depending on gfx board)
VoodooMem 30 (I have a Voodoo 4 so this will likely be different for you)
Ethernet = 0
I have no MMU variable and MedConfig isn't asking me about one. I'll manually set it and see what happens.
Edit: Setting MMU didn't seem to change anything.
The Radeon Memory is set to 32 and RadeonMemOS = YES.
Library and device versions:
Libs:68060.library 43.4 Mu/MMU.lib from ThoR
Devs:Networks/FastEthernet.device 1.25
Libs:pci.library 9.7
Libs:Picasso96/Voodoo.card 4.34
Note that some of my versions are older because of new bugs.
I'm using the same 060 library and fast ethernet device.
My PCI library is 9.10 though.
Genesis isn't that bad is it? It has a GUI with a choice of ClassAct or MUI and it is fast.
My Genesis prefs:
(Interface tab)
Name: FastEthernet
Comment:
IP Address: 192.168.0.100 (static)
Destination: (dynamic)
Gateway: 192.168.0.1 (static)
NetMask: 255.255.255.0 (specify)
MTU: 1500
Params:
Mine is set the same, plus your suggested changes from the eab thread, increasing the send and recv buffer sizes.
Thanks,
John
-
I have no MMU variable and MedConfig isn't asking me about one. I'll manually set it and see what happens.
Edit: Setting MMU didn't seem to change anything.
The Radeon Memory is set to 32 and RadeonMemOS = YES.
Yes, the directions have changed over the years but my old config still works. It's probably not the best for a new Radeon Mediator setup though.
I'm using the same 060 library and fast ethernet device.
My PCI library is 9.10 though.
I had problems with the new pci.library 9.8+. The screen will lose sync while using some Warp3D programs (Alan Thellier's Cow3D for example). I don't know if this would be a problem with 2D apps or the Radeon driver but there was at least one bug introduced after pci.library 9.7. The new pci.library is supposed to allow faster ethernet speed with fast ethernet but I wonder if it is broken or the timings are too tight for some setups.
You could try to find an old Voodoo 3 for testing. This would allow you to play with Warp3D programs also.
-
Yes, the directions have changed over the years but my old config still works. It's probably not the best for a new Radeon Mediator setup though.
I had problems with the new pci.library 9.8+. The screen will lose sync while using some Warp3D programs (Alan Thellier's Cow3D for example). I don't know if this would be a problem with 2D apps or the Radeon driver but there was at least one bug introduced after pci.library 9.7. The new pci.library is supposed to allow faster ethernet speed with fast ethernet but I wonder if it is broken or the timings are too tight for some setups.
You could try to find an old Voodoo 3 for testing. This would allow you to play with Warp3D programs also.
I've got a Voodoo, but I can't use resolutions that match my monitor with it. I did go back to pci.library 9.7, but I'm not sure if it was needed, I'm just staying there for safety sake right now.
For the time being, I've also gone back to Roadshow. I have better stability with it other than this one benchmark and it now seems to give similar performance to Genesis.
Who knows, it could be a bug there or I may find that I hit the bug during real-world use eventually.
I also found out that I could use netshutdown followed by addnetinterface to safely recover from the netio hang.
I'm able to get a bit over 1MBps now with the settings I'm using, both send and receive in netio (until it hangs and I have to ctrl-C) and using ftp from an in-house server. Those huge dips seem to be gone from what I can tell.
I set tcp.mssdflt to 536, the standard default size, and it actually seemed to help. 1500 is slower here, 1400 was better than 1500 and 536 seems completely safe and fast enough.
I raised the tcp.recvspace to 65536, but not the send. Raising both seemed to cause issues, but raising just this one seemed to pull up the receive to match the already good send speed. I think this was one of the biggest improvements.
In the interface, I set iprequests to 77 (a magic number from another thread that I'm now afraid to touch) and writerequests to 64. These seemed to also make a noticeable difference.
It still seems odd to get such slow speeds, but with the weak CPU and PCI implementation we have, that's probably about the best I can hope for.
-
Always thought it was funny how I got better networking and filesystem performance with Linux than with AmigaOS on same hardware, and on Linux I got a much more modern and feature rich IP stack too.
-
The Mediator throws a few things in the calculations, but most of the settings (such as MMU) have nothing to do with an 060 board. The graphics memory sets aside 32 MB (above) for uses as graphics, with 1 MB required for the pseudo-DMA and the rest under the later PCI.library useful as system RAM.
Note that the 1 MB pseudo DMA eats read/write cycles for every 1 MB of data transferred on the PCI bus.
-
I found something of use on eab, a netio benchmark from matthey using an 060/75 and Mediator.
I'm not sure my setup will actually complete the test, it seems to stop, but not lock up.
With the tweaks given here http://www.amiga.org/forums/showpost.php?p=751014&postcount=48 it just stops after giving Packet size 1k bytes: 923.34 KByte/s Tx and never seems to finish Rx.
Removing all the tweaks gives:
1K bytes: 901.88 KByte/s Tx, 946.49 KByte/s Rx.
2K bytes: 1067.00 KByte/s Tx,
Then it just stops again.
Edit: it seems that after running netio, Roadshow is no longer functional. GetNetStatus looks good, but not even ping will complete, it just sits there with no crash.
It can be dangerous to change the memory usage settings for the TCP/IP stack. Given enough traffic at a sustained high rate, the TCP/IP stack may end up consuming most available and usable memory (with respect to fragmentation, etc.).
I first saw this with AmiTCP V4, when I tested it with the X-Surf 100, and given that the underlying TCP/IP stack architecture is the same, right down to how the memory management works, Roadshow must be susceptible to the same issues.
Did you read the entire thread on which you found the tweaking information (there's some information on this subject in the Roadshow documentation, too)? There is more information to be found there, including how fast the X-Surf 100 can be expected to be, and under which circumstances.
In my own tests I found that 2.2 MBytes/s should be possible if you don't actually use the data transmitted. In reality with a web browser or an ftp client using the data transmitted you might get more than half of the 2.2 MBytes/s, and that's still a lot more than the Zorro II Ethernet cards can deliver. The X-Surf 100 is the fastest Amiga Ethernet card there is.
-
In my own tests I found that 2.2 MBytes/s should be possible if you don't actually use the data transmitted. In reality with a web browser or an ftp client using the data transmitted you might get more than half of the 2.2 MBytes/s, and that's still a lot more than the Zorro II Ethernet cards can deliver. The X-Surf 100 is the fastest Amiga Ethernet card there is.
X-Surf 100 has a jumper to switch between ZII and ZIII mode. Pretty sure I've seen numbers somewhere of folks getting as much as 6.6MB in ZIII. Might be mis-remembering, however.
-
In my own tests I found that 2.2 MBytes/s should be possible if you don't actually use the data transmitted. In reality with a web browser or an ftp client using the data transmitted you might get more than half of the 2.2 MBytes/s, and that's still a lot more than the Zorro II Ethernet cards can deliver. The X-Surf 100 is the fastest Amiga Ethernet card there is.
Probably a dumb question, but how is it that a RapidRoad connected to an X-Surf 100 in ZIII can get up to 6-7MB/sec (source: http://www.fitzstevesamigaworld.co.uk/?p=253 ), but Ethernet only 2.2MB? Is it all just protocol overhead? Seems like 2.2MB/sec isn't a bus limitation if RapidRoad can do so much faster through basically the same pipeline. ???
-
Probably a dumb question, but how is it that a RapidRoad connected to an X-Surf 100 in ZIII can get up to 6-7MB/sec (source: http://www.fitzstevesamigaworld.co.uk/?p=253 ), but Ethernet only 2.2MB? Is it all just protocol overhead? Seems like 2.2MB/sec isn't a bus limitation if RapidRoad can do so much faster through basically the same pipeline. ???
I know very little about how USB actually works, so this is a bit of speculation.
I reckon that the differences come about due to how much work the USB hardware does (as opposed to how much work the CPU has to do in addition to processing the incoming/outgoing data on Ethernet), how much freedom the implementors of the USB stack have (as opposed to the abstract "one size fits all" approach which the Amiga SANA-II network driver standard imposes) and how complex the underlying data transmission protocols are.
The type of Ethernet hardware we have to use for the Amiga is basically a data transport device, which sends or receives data which then has to be processed by software that, for example, has to verify or recalculate checksums, pick the structure of the data apart and make sense of it. This is by design, and not a side-effect. The CPU not only spends time on looking at the data, it also has to copy that data around 2-3 times between the network device and the application software using it. This adds up quickly.
In addition to shuffling the data around that comes and goes through the Ethernet device, the set of protocols which govern how the data flow is adjusted to the available bandwidth, and which detects and handles retransmission of missing data, is performed by the CPU as well. These protocols add a substantial layer of complexity, which is required by the fact that the data has to be able to travel a long way through several intermediate systems if necessary. So there is a lot of slack and elastiticy in these protocols to provide for this robustness, and that is just the opposite of what you would want in a fast data transmission system.
USB only has to cater for a local data bus which attaches peripheral devices such as hard disks or mice to your computer. There is no need to support mice connected to your computer by 10 km cables ;) Getting the data where it needs to be is also a lot simpler: the source/targets are all located on the same bus, whereas for TCP/IP the source and target could be anywhere on the local network or even the Internet.
Also, USB is likely designed so that the heavy lifting (more than just the basic work of doing error detection, retransmission, etc.) can be handled completely in hardware, with the computer tending only to the mandatory operations, such as handling device detection/removal, changes in the topology of the setup, and of course exchanging data between the computer and whatever is dangling out there.
Because there is nothing like the SANA-II networking standard for the USB stacks, and which today forces Ethernet hardware drivers to ignore all technical advances of the past 25 years, the USB stacks available for the Amiga can talk to the underlying hardware in any manner which they see fit, and which is likely best suited to the task at hand.
Now if you hooked up an Ethernet device to your USB setup, you might see that the overall throughput won't be in the same league as the basic USB data throughput. It would probably be a lot worse than what the X-Surf 100 can do all by itself.
-
Now if you hooked up an Ethernet device to your USB setup, you might see that the overall throughput won't be in the same league as the basic USB data throughput. It would probably be a lot worse than what the X-Surf 100 can do all by itself.
Thanks! Okay, that makes sense. I actually was assuming the opposite... that Ethernet could be handled more in hardware, so you've given me something new to ponder. ;)
I noticed Amazon has quite a few USB-to-Ethernet adapters available for sale (http://www.amazon.com/s/ref=nb_sb_noss_1?url=search-alias%3Delectronics&field-keywords=ethernet%20USB%20adapter). I googled terms like "speed of ethernet USB on Amiga", and came across this link (http://www.hd-zone.com/2011/07/ethernet-adapter-speeds-amigaos-3-9-and-amigaos-4-1-classic/), which seems to indicate in the charts at the bottom that a Deneb with USB Ethernet adapter is topping out at about 1MB/sec, with close to 100% CPU utilization. So 2.2MB/sec beats that, any day! ;)
-
It can be dangerous to change the memory usage settings for the TCP/IP stack. Given enough traffic at a sustained high rate, the TCP/IP stack may end up consuming most available and usable memory (with respect to fragmentation, etc.).
I first saw this with AmiTCP V4, when I tested it with the X-Surf 100, and given that the underlying TCP/IP stack architecture is the same, right down to how the memory management works, Roadshow must be susceptible to the same issues.
Did you read the entire thread on which you found the tweaking information (there's some information on this subject in the Roadshow documentation, too)? There is more information to be found there, including how fast the X-Surf 100 can be expected to be, and under which circumstances.
I read the thread and the documentation carefully, although I may have missed something.
In my own tests I found that 2.2 MBytes/s should be possible if you don't actually use the data transmitted. In reality with a web browser or an ftp client using the data transmitted you might get more than half of the 2.2 MBytes/s, and that's still a lot more than the Zorro II Ethernet cards can deliver. The X-Surf 100 is the fastest Amiga Ethernet card there is.
You do realize that I don't have an X-Surf 100, right? I'm asking about an A4000 Mediator tower with Realtek 8139D 10/100 card.
I have never seen anything stating what can be expected from a Mediator like mine until I found Matt's netio output that I listed above.
-
I read the thread and the documentation carefully, although I may have missed something.
There are two aspects which I hope to have made clear in the documentation: 1) Roadshow ships with reasonably safe defaults which do not necessarily provide best performance and 2) tweaking Roadshow to improve performance is possible and recommended, but it has its limits and drawbacks.
You do realize that I don't have an X-Surf 100, right? I'm asking about an A4000 Mediator tower with Realtek 8139D 10/100 card.
Yes, I am aware of it. However, the limitations of both the X-Surf 100 and the Realtek card that can be used with the Mediator are sufficiently similar: it's not the network interface, but what surrounds them ;)
TCP/IP network performance on the Amiga is limited by CPU speed, memory performance, network interface performance and TCP/IP stack architecture.
With the older Zorro II based Ethernet cards the limitations imposed by CPU and memory performance were not the bottleneck: the Zorro II bus and the capabilities of the interface (10 MBit/s) were. The TCP/IP stack architecture's limitations were practically irrelevant because the Zorro II bus and the 10 MBit/s Ethernet masked them. With a sufficiently fast CPU and high performance memory you could squeeze as much out of the 10 MBit/s Ethernet interface as the hardware allowed: I've tested this on an A3000T with an 68040 WarpEngine, for which Roadshow delivers almost 10 MBit/s with an Ariadne card.
With the X-Surf 100 and the Mediator the situation changed. The network interface no longer was the bottleneck, but the TCP/IP stack architecture became the limiting factor. All Amiga TCP/IP stacks which trace their lineage back to 4.2/4.3/4.4BSD Unix use intermediate buffers to move data between the application software and the network devices, and that involves up to three copying operations before the data is where it is supposed to be. This impacts the "CPU time budget", restricting how much data you can actually consume or produce in application software. On my test machine (that A3000T with the WarpEngine) I managed to obtain a raw transmission rate of 1.7 MBit/s with both Roadshow and AmiTCP Genesis, at 100% CPU load. If the CPU were faster, the transmission rate would have been higher.
I have never seen anything stating what can be expected from a Mediator like mine until I found Matt's netio output that I listed above.
I ported the netio tool natively to the Amiga, and rewrote the older tcpspeed tool (written by Holger Kruse for Miami/Miami Deluxe) so that their measurements would be more accurate, and to cut down on transmission overhead. When I was testing the X-Surf 100 I wanted to be able to reproduce the netio test results I had read about. It turned out that the netio test results vary greatly, up to 40% between subsequent runs, so I would advise caution if you wanted rely exclusively upon them.
If you are using the original netio version, you are using ixemul.library for network operations, so there could be a bit more overhead involved than would be necessary. The netio port I made runs fine without depending upon anything other than bsdsocket.library.
If you are curious how these tools are measuring performance, please contact me via PM. I could send you the tools, with source code, if you like.
-
Well, 100 Mb/s (megabits per second) equals 12.5 MB/s (12.5 megabytes/sec) with no overhead (error checking,mostly), but only about 50% can be used, so 50 Mbits/s data transfer =~ 4.7 to 6.0 MB/s (max). Now you are getting < 1 MB/s, so there is a bottleneck. The Buster chip limits the estimated 150 MB/s Zorro 3 speed to about 13.5 MB/s and the limit on Amiga to PCI card in a Mediator seems a max of 12 MB/s. Jens of icomp.de says, "Roadshow is a commercial product still available today, but since it does not reach the speeds that AmiTCP/Genesis can reach" but I can't find results of his testing. He does state elsewhere, "Transfer rates of over 1600kBytes/s [1.6 MB/s] have been measured with the X-Surf-100. Please note that the classic Amiga architecture and the current TCP/IP stacks for the Amiga don't allow saturating a 100MBit Ethernet link. Performance in your system may be slower due to CPU performance and programs running in multitasking."
I think that somewhere in there is your answer.
You can reach 94-97 Mbps on a FastEthernet interface. But you won't reach that on your 'Classic' Amiga of course.
-
Oh, I didn't know that
-
You can reach 94-97 Mbps on a FastEthernet interface.
Sorry dude. I'm gonna let Bill & Ted take it from here. ;)
(http://img.pandawhale.com/94276-bill-and-ted-bogus-gif-Imgur-rWed.gif)
-
Nothing bogus about duga's claim, not sure what you aim at Mike.
-
Well, at least the 94 Mbs is reachable in a closed laboratory setting between two PC's with no hubs and using ttcp (Test TCP) provided the "sender" only sends and the "receiver" only receives.
But, to the best of my knowledge we were talking about Amiga and their Ethernet cards and throughput over the Zorro 2/3 bus, multitasking, error checking and the like.
-
Well, at least the 94 Mbs is reachable in a closed laboratory setting between two PC's with no hubs and using ttcp (Test TCP) provided the "sender" only sends and the "receiver" only receives.
Not at all, you can reach those levels also with NFS across LANs, most equipment today is gigabit anyways. And full duplex means that you can both send and receive without one affecting the other.
But, to the best of my knowledge we were talking about Amiga and their Ethernet cards and throughput over the Zorro 2/3 bus, multitasking, error checking and the like.
Your knowledge is failing then, what he wrote was:
"You can reach 94-97 Mbps on a FastEthernet interface. But you won't reach that on your 'Classic' Amiga of course."
-
Those speeds are easily obtainable with modern hardware, no "test environments" needed, as Kolla says. I do it every day of the week at those speeds and higher over my gigabit network to my NAS box using a $200 L2 managed switch, no rocket fuel or magic involved.
-
over my gigabit network
He's saying he gets 97Mbps throughput on his Fast Ethernet (http://en.wikipedia.org/wiki/Fast_Ethernet) (which is 100Mbps, not gigabit) network. That would mean he's getting 97% efficiency with zero protocol overhead, etc. I'm calling BS on that. But regardless, TL;DR, off-topic for the thread, carry on folks. :)
-
Sheesh, FFS!!
He said FastEthernet *interfaces*, not network, stop twisting this around! Today equipment is typically geared toward Gbit speeds, and yeah, 97% efficiency on 100Mbit interfaces is quite doable - nowhere did he mention protocol overhead, because that is irrelevant when it comes to measing efficiency of *hardware*. You chose to use a slow protocol with lots of overhead, that your effin problem!
-
He said "You can reach 94-97 Mbps on a FastEthernet interface". FastEthernet is a technical term for a specific type of connection that I'll be damned if you will ever get 97 Mbps real-world throughput on. Not on it's best day, with all your prayer beads in a row. But yeah, whatevs, really. "Xerox" used to be a specific thing, too. Now it just means "make a copy". Google used to be a brand name. Now it's just a verb to say "I did a search on the Internets". Blah blah. Have a nice day! :)
-
Well, I'm sorry to see you strugling with your network, as well as your grammar.
-
Well, I'm sorry to see you strugling with your network, as well as your grammar.
Unnecessary and stupid personal attack. Thanks for keeping this thread classy! Sorry I get my head bit off for trying to correct someone, I know how much this site likes actual facts! :roflmao:
-
Oh, facts. Too bad I'm far away from any hardware to do performance tests myself for you, but here is a paper on throughputs with various Windows releases, notice how most numbers are well above 94% efficiency.
http://www.zti-telecom.com/BrochuresN/LanTraffic%20V2%20%28V2.6%29%20Performances%20Measurements.pdf
As for "personal" attack, consider it a tongue in cheek attack on all your countrymen, who seem to strugle so hard with what you consider your own language (which btw, it is not)
-
Since some people have resorted to personal insults, the above mentioned document references results using a specific benchmark in a test lab.
The English language is a rough development of old German (both "Anglo" and "Saxon" are from German regions) with addition of Latin derivations and words that transcend country boundaries. Spelling and grammar differ from the US to that used in Canada and the UK. Aside from some small typing errors that could be colloquialisms, his grammar is fine. Some people's use of "effin" for fornication is not, or at least I would never have turned in a document in undergrad or grad school with that word in it; furthermore it is insulting.
-
http://en.wikipedia.org/wiki/Ethernet_frame#Maximum_throughput
http://packetpushers.net/tcp-over-ip-bandwidth-overhead/
"If you add Ethernet (and VLAN tagging) into the mix (see the calculations from Wikipedia here) then the throughput of a 100Mb link is 100 X 0.9733 (TCP/IP efficiency) x 0.9728 (Ethernet (with tagging) efficiency) which equals 94.68Mbps, which I assume means the combined efficiency is 94.68%."
-
Thanks for sharing the PacketPushers article, Duga - very well written and I'd hadn't seen it before.
-
Well, at least the 94 Mbs is reachable in a closed laboratory setting between two PC's with no hubs and using ttcp (Test TCP) provided the "sender" only sends and the "receiver" only receives.
But, to the best of my knowledge we were talking about Amiga and their Ethernet cards and throughput over the Zorro 2/3 bus, multitasking, error checking and the like.
As stated, and kindly read the second article for "Assumptions" and "Other Overheads" since this is not a real-world calculation.
-
http://en.wikipedia.org/wiki/Ethernet_frame#Maximum_throughput
http://packetpushers.net/tcp-over-ip-bandwidth-overhead/
"If you add Ethernet (and VLAN tagging) into the mix (see the calculations from Wikipedia here) then the throughput of a 100Mb link is 100 X 0.9733 (TCP/IP efficiency) x 0.9728 (Ethernet (with tagging) efficiency) which equals 94.68Mbps, which I assume means the combined efficiency is 94.68%."
The figures quoted refer to efficiency in terms of bandwidth used by and available for the payload (as opposed to the protocol overhead), and they specifically exclude the work needed to get the data from one place to another, which would also have to account for the effects of memory management in the TCP/IP stack and whatever the operating system has to do at the time.
That is to say the 97% efficiency figure probably does not translate into practical throughput of 97 MBit/s on Fast Ethernet. It's likely a bit lower.
-
Sheesh, FFS!!
He said FastEthernet *interfaces*, not network, stop twisting this around!
The question asked was about ftp transfers using a Mediator, the answer he gave is a theoretical maximum you can push through an Ethernet PHY when you don't have annoying things like a cpu/ram/bus/os to get in the way.
His answer was unhelpful at best, misleading at worst.
-
The question asked was what is the expected network throughput on Mediator, the answer he gave is a theoretical maximum you can push through an Ethernet PHY when you don't have annoying things like a cpu/ram/bus/os to get in the way.
You should include "physics" in that list, too ;) Signal propagation speed and latency need to be taken into account as well.
-
What this started with was Oldsmobile claiming that 94-97Mbit on a fastether interface is BS. It is not, and you don't need a "lab setup" to prove that, just hook a fairly modern machine with a fastether NIC to a modern switch and do your measuring. There is no difference in a "lab" and real world here, the equipment is the same.
-
What this started with was Oldsmobile claiming that 94-97Mbit on a fastether interface is BS. It is not, and you don't need a "lab setup" to prove that, just hook a fairly modern machine with a fastether NIC to a modern switch and do your measuring. There is no difference in a "lab" and real world here, the equipment is the same.
I was really just going to ignore you, but please remind us again how all your trolling about "theoretical maximum throughput" helps this guy with his Mediator question at all?
-
Sheesh, FFS!!
He said FastEthernet *interfaces*, not network, stop twisting this around! Today equipment is typically geared toward Gbit speeds, and yeah, 97% efficiency on 100Mbit interfaces is quite doable - nowhere did he mention protocol overhead, because that is irrelevant when it comes to measing efficiency of *hardware*. You chose to use a slow protocol with lots of overhead, that your effin problem!
But you haven't explained what part the Fast File System plays in this?
-
But you haven't explained what part the Fast File System plays in this?
Paul1981 is quite correct (but more to the point about Amiga HDD transfers); those people spitting out "Theoretical" and "Lab Results," fail to remember that the "lab" part is from RAM to Ethernet to RAM. The original question was on an Amiga doing FTP which involves HDD to Mediator to Ethernet to Server HDD. These Real World transfers eat CPU cycles and are limited by bus speeds and finally the file system (to some extent), further the server is an unknown and we can't guess the efficiency of it.
I'm going to "guess" that if Jens can get a lab result under optimal conditions for his X-surf 100 of 1600kBytes/s [1.6 MB/s] , then a plain 8139 card sitting on a Mediator that transfers to a Z3 bus and then to a hard drive is going to achieve a value significantly less.