Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: matt3k on October 03, 2013, 05:41:28 PM
-
Currently I own Ariandne with MNI drivers in Miami, and working for the big speed increase...
Getting funds together to buy this awesome card and was wondering:
Is roadshow the fastest for the card?
What is the best TCP/IP stack for multitasking and system performance?
Anyone using roadshow with this card?
Appreciate the feedback...
-
Hi
We provide EasyNet (http://www.amigakit.com/easynet) free with the X-Surf 100 (http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=1156) card. This should provide really good performance with more developments coming.
-
Currently I own Ariandne with MNI drivers in Miami, and working for the big speed increase...
Getting funds together to buy this awesome card and was wondering:
Is roadshow the fastest for the card?
What is the best TCP/IP stack for multitasking and system performance?
Anyone using roadshow with this card?
Appreciate the feedback...
Funny you should ask, as I recently did a little testing to answer just that question. Courtesy of Jens Schönfeld, who loaned me a sample for testing. For the record, the "X-Surf 100" is the fastest Amiga Ethernet card ever made (if used in Zorro III mode, and connected to a 100 MBit/s or 1 GBit/s switch). You can quote me on that.
First thing, any TCP/IP stack you can buy today is going to be faster than "Miami", even with MNI drivers. That goes for both "AmiTCP Genesis" and "Roadshow".
If you have an A3000 or A4000 then the "X-Surf 100" will send and receive data faster than your Amiga will be able to process. With the "Ariadne", it's the other way round: the computer is faster than the Ethernet card. The "Ariadne" limits how fast you can send and receive data.
But that's not the case with the "X-Surf 100". No matter which TCP/IP stack you use ("Miami" probably being the exception, because its SANA-II network support limits how fast it can go), you're probably not going to see much of a difference between "Roadshow" and "AmiTCP Genesis" in terms of speed: the "X-Surf 100" is the great leveler.
"Roadshow" plays to its strengths when it comes to make the most of available memory and CPU power, especially if you don't have a high end Amiga or a high end Ethernet card. If you have lots of memory, and a very fast CPU (say, 68060@50MHz), "Roadshow" won't provide more punch than "AmiTCP Genesis", when using the "X-Surf 100" in Zorro III mode, and you transmit data under full load. I do believe, however, that "Roadshow" does well enough with modest means, i.e. you don't have to throw a lot of memory at it in order to get it up to speed.
What I found interesting is how much the CPU power matters in terms of TCP/IP stack performance. In my TCP transmission tests (in the local network) I got about 1.700 MByte/s out of the "X-Surf 100", on my test machine which I used for benchmarking "Roadshow". (Note that I did not conduct tests between the A3000T and the Internet, since measuring network performance for this application is very hard to do reliably. You're not just pushing data around between a source and a destination, but a lot of intermediary systems, too. Talk about reproduceability...)
Both "Roadshow" and "AmiTCP Genesis" ran about exactly as fast in my tests. My test machine is an A3000T, with a WarpEngine 68040@40 MHz. I read about a CyberStorm Mk II, with a 68060@50 MHz, getting about 2 MByte/s out the "X-Surf 100", and I believe that's a realistic figure.
Note that when the "X-Surf 100" is transmitting data at this speed, your CPU load will be at 96%, if not higher. This is because no currently existing Amiga TCP/IP stack supports offloading tasks such as checksum calculation/verification or data transfer to the networking hardware. Whenever an Ethernet frame enters or leaves the "X-Surf 100", it will be your computer's CPU pushing it along. Whatever CPU cycles are still left, while the "X-Surf 100" is running under full steam, so to speak, your networking software may put to good use. Both the TCP/IP stack and your networking software will be competing aggressively for the CPU.
Because so far Amiga networking hardware was very slow, we never had a case of the CPU power being the limiting factor when it comes to network I/O performance. Bottom line is, if your CPU is very fast, then the network I/O performance will be high. If not, then performance will be proportionately lower.
In my personal tests of the card and its driver software, I found that it was almost twice as fast as the original "Ariadne", which is the fastest Zorro II Amiga Ethernet card I know of. With a high end Amiga configuration, I reckon that it the "X-Surf 100" will be a bit more than twice as fast as the "Ariadne". I think sustained transmission rates of more than 2.2 MByte/s may be possible.
That's as much as I found out, during my own personal testing (your mileage may vary). If anybody's interested in doing their own test, I'm happy to share the source code of the benchmarking programs which I used for testing, and the test methods.
-
@Olsen
Thanks!
I'm using a 3000D with a CS MKIII 060-50.
I will use the easynet front end and hope they update it to work with lpr.device in the near future for printing.
One issue I had with the Ariandne and my Delfina Plus, is that if I copied large files from my NAS and played "insane" mp3's, (If I copy smaller files and/or played normal mp3's there is no issue) I would get stuttering playback. The Delfina Plus only uses 2% CPU, so I thought it was bus related. Perhaps this may be CPU, and will not go way with the X-100.
Guess I will have to test that one...
Again thanks for sharing...
-
@Olsen
Thanks!
I'm using a 3000D with a CS MKIII 060-50.
Looks like you've got the right gear to make the most of the X-Surf 100 then.
I will use the easynet front end and hope they update it to work with lpr.device in the near future for printing.
Well... should you ever get curious, the free "Roadshow" demo will still be available for evaluation. Plugging in "lpr.device" in the services configuration file should not be too hard. Come to think of it, I'll make a note to add a sample entry for it.
One issue I had with the Ariandne and my Delfina Plus, is that if I copied large files from my NAS and played "insane" mp3's, (If I copy smaller files and/or played normal mp3's there is no issue) I would get stuttering playback. The Delfina Plus only uses 2% CPU, so I thought it was bus related. Perhaps this may be CPU, and will not go way with the X-100.
It probably will not get worse either. How you describe it, it seems to me that the issue may be with the size of the mp3 decoding buffer.
If the file to be played is small, it will transfer quickly over the network while the player can either still keep up with decoding, or will decode it just in time for the network access not to have a negative impact on it. But if the file is large enough, decoding, playback and reading more data off the network will happen in parallel. Because the decoder and the TCP/IP stack are competing for the CPU, playback quality inevitably suffers.
I had the same problem with the "Concierto" add-on for the Picasso IV. Because the "Concierto" hardware was interrupt-driven and could not use DMA (on top of that the sound chip had its own quirks), playback always consumed CPU time. Playing back mp3 files on the "Concierto" left little CPU time to other tasks. You could either listen to the music or do something else, but not both.
Now if you had a larger decoding/playback buffer, it might be that the player will be able to feed audio data to the Delfina Plus more easily while it's reading more data from the network. Increasing the buffer size, if that is possible, would be the classic remedy for this kind of problem.
-
Using RoadshowPPC and the X-Surf 100 in OS4.1 shows not more than 24% CPU utilization with the overhead browser (IBrowse) or 18% with the overhead of AmiFTP transfers. Like all of the referenced numbers in this thread, this is Anecdotal and has no statistical validity. Test Bed numbers apply only to the testing hardware, software and network at hand and thus have no more than a casual relationship to Real World numbers. I feel you have to ignore the numbers unless you perform quite extensive real world testing and then calculate a meta-analysis of those results to get a generalized pictured of the throughput "in the wild."
My conclusion is that it "feels" fast, in the same ballpark (but not over the fence) as a USB 10/100/1000 dongle off a Deneb in Z3 PIO under OS4.1.
-
Thanks Olsen,
I increased the buffer in AmigaAmp to 'File' and it works perfectly now! No more stuttering playback. Works perfect with the Ariandne.
My X-Surf 100 arrives today, so the only outstanding issue is the update of Easynet for V4 so I can print.
Again thank you for the help.
Will let you know the speed comparison between the Ariandne and the X-surf. Initially I will just use Miami until the updates to Easynet take place.
What test do you recommend for calculating speeds of the cards?
Looks like you've got the right gear to make the most of the X-Surf 100 then.
Well... should you ever get curious, the free "Roadshow" demo will still be available for evaluation. Plugging in "lpr.device" in the services configuration file should not be too hard. Come to think of it, I'll make a note to add a sample entry for it.
It probably will not get worse either. How you describe it, it seems to me that the issue may be with the size of the mp3 decoding buffer.
If the file to be played is small, it will transfer quickly over the network while the player can either still keep up with decoding, or will decode it just in time for the network access not to have a negative impact on it. But if the file is large enough, decoding, playback and reading more data off the network will happen in parallel. Because the decoder and the TCP/IP stack are competing for the CPU, playback quality inevitably suffers.
I had the same problem with the "Concierto" add-on for the Picasso IV. Because the "Concierto" hardware was interrupt-driven and could not use DMA (on top of that the sound chip had its own quirks), playback always consumed CPU time. Playing back mp3 files on the "Concierto" left little CPU time to other tasks. You could either listen to the music or do something else, but not both.
Now if you had a larger decoding/playback buffer, it might be that the player will be able to feed audio data to the Delfina Plus more easily while it's reading more data from the network. Increasing the buffer size, if that is possible, would be the classic remedy for this kind of problem.
-
OK, installed the x-surf 100.
Using Miami right now and it is barely faster than the Ariandne.
Ariandne with MNI gives 155,000 cps and 25% cpu.
X-Surf with SANA2 gives 170,000 cps and 15% cpu.
Oh well. Hopefully when I figure out how to install AmiTCP with Easynet, the results will double...
-
OK, installed the x-surf 100.
Using Miami right now and it is barely faster than the Ariandne.
Ariandne with MNI gives 155,000 cps and 25% cpu.
X-Surf with SANA2 gives 170,000 cps and 15% cpu.
Oh well. Hopefully when I figure out how to install AmiTCP with Easynet, the results will double...
The whole point of EasyNet is the ease of installation, given a few router parameters; although Roadshow lacks a GUI, it is pretty much a dead simple install: install the software, copy one file (the NIC card settings from storage to device), make sure the correct driver is in the Devs:Networks folder, and reboot.
-
Ariandne with MNI gives 155,000 cps and 25% cpu.
X-Surf with SANA2 gives 170,000 cps and 15% cpu.
Is the difference DMA usage? it seems like a significant difference.
-
What test do you recommend for calculating speeds of the cards?
I use "synthetic" tests to gauge performance, which as danbeaver pointed out, have little relevance for real world applications. Still, these tests can be easily repeated, the results are reproduceable and comparable.
For my recent tests, I ported the NetIO program to the Amiga and reworked the TcpSpeed program, which I believe was written by Holger Kruse, who also wrote Miami/Miami Deluxe. Both programs require Kickstart 2.04 and a plain 68000 Amiga (i.e. they both work on an A600).
The reworked TcpSpeed program tries to measure the throughput more accurately by resorting to timer.device measurements and using floating point numbers to calculate the figures.
Both NetIO and TcpSpeed perform data throughput tests, i.e. they transmit fixed amounts of data between a sender and a receiver and measure how long it takes for the last byte to arrive. From these figures they calculate the average data throughput.
For the tests to work you need two computers. One acts as the test server, the other as the test client. The test server in my case was a Mac Mini, and the client was an A3000T. Both were connected by a Gigabit Ethernet switch.
Programs and source code are available from me only for now. I have not yet uploaded them to Aminet. If you are interested, please contact me via PM.
-
OK, installed the x-surf 100.
Using Miami right now and it is barely faster than the Ariandne.
Ariandne with MNI gives 155,000 cps and 25% cpu.
X-Surf with SANA2 gives 170,000 cps and 15% cpu.
Oh well. Hopefully when I figure out how to install AmiTCP with Easynet, the results will double...
The Miami SANA-II support leaves much to be desired in terms of performance. Considering how fast the X-Surf 100 actually is, seeing that with Miami it runs faster than the Ariadne, even when using SANA-II drivers, should tell you something :)
-
Is the difference DMA usage? it seems like a significant difference.
Neither the Ariadne nor the X-Surf 100 support DMA.
If X-Surf 100 did support DMA, and the TCP/IP stack would so, too, then the figures would be much, much higher.
The problem here is that the Miami SANA-II support is not as good as it ought to be, and obscures how fast the X-Surf 100 really is.
-
This just tells me that AmigaOS need a new network driver infrastructure..
-
This just tells me that AmigaOS need a new network driver infrastructure..
It already has that in OS 4.1.
-
This just tells me that AmigaOS need a new network driver infrastructure..
Miami has always been known to be slow. It was my understanding that the key checking and such holger had in the code really slowed it down also.
roadshow on the same hardware is usually good for quite a speed increase.
Maybe it is time for SANAIII :) olaf?
-
It already has that in OS 4.1.
For classic OS that is :P
-
Will configure Easynet tonight and report back.
Interesting I ran speed tests later and the cpu usage went way up (as I expect from Olsen's tests).
The first speed test was only 15% cpu now she is in the 90s%. And I feel the slowdown when using the Amiga. MP3's play perfectly still but sluggish behavior has creeped into play...
Hoping for much better speed with EasyNet, and hopefully better cpu.
The Ariandne with MNI is really fast and multitasks very well. Guess Maxing out 10mbs leaves the cpu free to count sheep...
-
This just tells me that AmigaOS need a new network driver infrastructure..
It's not so bad. The thing that's missing is a set of data structures to accomodate modern networking hardware, allowing the driver to offload the copying operations which currently slow down 100 MBit/s Ethernet traffic.
The remaining parts of the SANA-II standard do hold up pretty well, even after more than 20 years.
-
It already has that in OS 4.1.
Not really. The network drivers for OS4 still use the same SANA-II standard as the TCP/IP stack (which is the PPC version of Roadshow). Everything SANA-II revision 5 can do can be done on 68k Amigas (and of course MorphOS), too.
-
Miami has always been known to be slow. It was my understanding that the key checking and such holger had in the code really slowed it down also.
roadshow on the same hardware is usually good for quite a speed increase.
That sounds like a technically convoluted approach to the task. If it slows down the main task of the software to a degree where it really suffers in terms of performance, something is deeply wrong with the implementation.
My best guess is that the I/O code in Miami just didn't get revised/reworked as it would have been over the years. Holger went out of business before that work could have taken place.
Maybe it is time for SANAIII :) olaf?
SANA-II is solid, but it doesn't support the kind of networking hardware well which has been around for "only" 15-18 years now. It was designed for the type of Ethernet gear which was available in 1987-1990, and that it supports well.
In my opinion "all" it takes to make SANA-II work better with modern Ethernet hardware would be to standardize support for offloading work (copying, calculating checksums, verifying checksums) to the hardware. This has been tried before, and it requires support both in the driver and the networking software which uses it (e.g. a TCP/IP stack such as Roadshow).
Given that the Amiga market has slowly turned into a hobbyist affair, there just doesn't seem to be as much fun in working out the details of getting samples of how different the hardware is that needs to be supported, finding common ground, putting together an example implementation, reviewing the results and then deploying it.
-
The Amiga network drivers suffers from inefficient buffer handling scheme and proper support for promiscuous and multicast modes. On top of that there's some version requirement too.
It's a mess!
-
The Amiga network drivers suffers from inefficient buffer handling scheme and proper support for promiscuous and multicast modes. On top of that there's some version requirement too.
It's a mess!
Perhaps it's old age setting in, but I'm not so pessimistic about SANA-II. Having worked with it for almost 15 years, I may have gotten used to the quirks.
Inefficient buffer handling, yes, that's the big one. However, it only hurts if you use it with a modern NIC ;)
Proper support for promiscuous mode is missing, i.e. there is no SANA-II command for changing or querying it. The best one can do is to use the S2_READORPHAN command and hope for the best.
The multicast support sort of works, and you even have a choice of two different commands to do the job (ha!). Mind you, neither of these will allow you to receive multicast packets from arbitrary addresses. They either have to be within a certain range, or you have to use one and only one address to listen to.
I wouldn't call this a mess. Unless you badly need this functionality (multicast comes to mind), I'd say the vast majority of users can squeak by without realizing what is missing. The limitations of the buffer handling are the most annoying thing.
What do you mean by version requirements?
-
Only working on some OS versions.
I just think it would be a serious improvement to get a clean and efficient API.
-
Weird, just plain weird.
EasyNet is slow only getting 30,000 cps. Tried increasing the buffers to 4096 with no change.
The only thing I can even think of, is that I had to switch to opendns for dns to even make EasyNet work. Road Runner DNS will not work in EasyNet but work fine in Miami. Could this impact download speed?
For a while my cpu was spiking to 90%, but now it's back down to 15% with either Miami or EasyNet.
Miami SANA2 peeked at 200,000 this morning and 15% cpu.
-
Only working on some OS versions.
In which context? I can't say I have heard about this before. Except perhaps concerning the A2065 driver, which for many years was quite poor in terms of robustness and speed.
I just think it would be a serious improvement to get a clean and efficient API.
What do you have in mind, specifically?
-
Weird, just plain weird.
EasyNet is slow only getting 30,000 cps. Tried increasing the buffers to 4096 with no change.
Careful with these settings, they don't necessarily have the impact which their names may suggest. Change the wrong combination of settings, and you'll render your TCP/IP stack "combat ineffective".
Do you have the latest x-surf-100.device installed? The version I ran my tests with was V1.11, released on September 16: http://wiki.icomp.de/wiki/X-Surf-100
The archive which contains the driver also contains an example "AmiTCP.config" file which turns up the memory dials to 11 and which will improve data throughput. Careful though, these settings don't necessarily work robustly and may have side-effects: they throw a lot of memory at the task. Less memory may still work, but so far nobody has suggested how much less.
The only thing I can even think of, is that I had to switch to opendns for dns to even make EasyNet work. Road Runner DNS will not work in EasyNet but work fine in Miami. Could this impact download speed?
Not unless you're constantly performing DNS lookups, which I consider unlikely. AmiTCP doesn't have a DNS cache (Roadshow does), so if DNS lookups for the same name are frequent, then it will spend considerably more time performing them.
DNS lookups failing is usually a sign of network trouble. A DNS lookup is usually performed by sending UDP packets to the DNS server and then waiting for it to respond. If the packets are corrupted during transmission, or get lost, the lookup may be repeated later. But there is a long timeout before the lookup is retried, and if that doesn't work out again, things will get unpleasant.
As a rule, you should use your ISP's DNS server if you can, because the likelyhood of losing packets is smaller with them than with a different DNS server, e.g. OpenDNS or even Google: the packet don't have to travel very far.
I can perfectly understand if you don't want to use your ISP's DNS server, though. Mine is known to produce responses which do not reflect the original queries. Because DNS security is so brittle, I rather run my own DNS server at home and use that instead.
The next best thing is to have your gateway router do the DNS lookups, cache these, and make your Amiga use it. Find a trustworthy DNS server and stick with it (try http://www.opennicproject.org/).
For a while my cpu was spiking to 90%, but now it's back down to 15% with either Miami or EasyNet.
Miami SANA2 peeked at 200,000 this morning and 15% cpu.
To me this looks like you might be dropping packets.
-
@Olsen
Thanks for the help, it is truly appreciated.
I will continue to run EasyNet vanilla for now.
I am using the latest device 1.11 and I will look into the config file.
I noticed that I can spike the cpu if I use samba and copy from my NAS, but using Ibrowse it is very inconsistent (mostly around 15%) even with copying large files from aminet. With either stack I'm getting the same cpu but much different results.
I will do a peer to peer test that you use later to see how the numbers change.
I will check out the DNS provider you suggest.
Thanks again and I will check back when I complete the tests.
-
Tried the AmiTCP.config file from the archive and it only got me to 60,000 cps.
Also set up AmiTCP with the suggested DNS server, no difference.
The only things I can think of is:
1. When I download the update via easynet, is seems extremely fast. Best guess at least 250000 cps.
2. I haven't changed my router away from road runner dns yet. Maybe it is conflicting with amitcp settings and the opendns.
3. Raw copies accross network seem much faster. For downloading from aminet, Miami is 4 times faster (again pointing to DNS)
Do I need to change my router over also or can amitcp access a different dns with out issues?
-
Tried the AmiTCP.config file from the archive and it only got me to 60,000 cps.
That should have made a difference. But, well, it's not the change that I would have expected. Bummer.
Also set up AmiTCP with the suggested DNS server, no difference.
I don't know how this works with AmiTCP, but I'd suggest you have a look at what the TCP/IP stacks says to how many errors cropped up during the transmission. On a Unix system that would be done through a shell command called "netstat", e.g. "netstat -s".
The only things I can think of is:
1. When I download the update via easynet, is seems extremely fast. Best guess at least 250000 cps.
2. I haven't changed my router away from road runner dns yet. Maybe it is conflicting with amitcp settings and the opendns.
If you select a specific DNS server pair in AmiTCP then this is what will be used, regardless of what the router wants to use. Your ISP may or may not manipulate outbound DNS queries and the corresponding results. It's technically possible, and if you're living in the UK, it might actually happen.
3. Raw copies accross network seem much faster. For downloading from aminet, Miami is 4 times faster (again pointing to DNS)
No, this probably isn't it. DNS has one responsibility only, and that's mapping human-readable names such as "www.amiga.org" to IP addresses, such as 50.87.149.192 (and the other way round, too).
Your networking application software (ftp client, IRC client, web browser) will start by querying the IP address associated with a name, and once it knows the answer, will proceed to open a connection to the IP address.
Once the connection is up, the web server or ftp client can start transmitting data. At this point your choice of DNS server is probably completely irrelevant for the performance of the data transmission. "Probably" because in certain cases network services may be used to pick the closest available server, based upon where your DNS query originated. This is how, for example, content distribution networks (e.g. Akamai) may optimize delivery. If you're unlucky, you might end up getting the IP address of a server which is not optimal for your place in the internet.
What else could be slowing things down? If you're sharing the internet link with somebody else, it could be this person's network traffic getting in the way. If you live in (sort of) a backwater town (like I do), it could be the poor quality of the broadband connection which due to signal attenuation restricts how fast you can go. In my case, on a bad day I've got 6.5 MBits/s (downstream), and on a good day it's 9 MBits/s (both are pretty far from the advertized 15 MBits/s). Finally, your ISP could be limiting your traffic on purpose.
Do I need to change my router over also or can amitcp access a different dns with out issues?
Whatever you set up in AmiTCP counts. Unless your ISP filters the DNS packets which pass through your network and chooses to alter it.
-
If you select a specific DNS server pair in AmiTCP then this is what will be used, regardless of what the router wants to use. Your ISP may or may not manipulate outbound DNS queries and the corresponding results. It's technically possible, and if you're living in the UK, it might actually happen.
I have actually come across some routers which defy this rule. Some older Engenius routers (I stopped using the damned things, so I cannot speak about newer units,) some Belkin, and a couple of D-Links were culprits in breaking Windows Server DNS services. I was able to show that the routers were intercepting DNS packets. I some cases the inbound was blocked, forcing the server to use the router for DNS. In other cases, outbound DNS packets were being usurped, and this caused huge issues with EDNS queries as none of these routers support EDNS so queries would be delayed, broken in sequence, or in most testing simply dropped.
It's easier to tell what's happening with your queries if you have access to an outside DNS server's logs. But it's not impossible otherwise.
-
What do you have in mind, specifically?
* Option for DMA and various memory setups + bus types (zorro/pci)
* Proper handling of promiscuous and multicast modes
* Orthogonal command set. No "S2_MISC" + "EXTRAS_PROMISC" etc..
* Options for offloading checksum calculations and verifying checksums
* Support for all AmigaOS versions
* Option for PPC/ARM/x86
* Hardware agnostic as possible
* Backwards compatible with AS225, SANA-II, MNI if possible (so one can use a network card with SANA-II driver with an application that requires MNI etc)
-
I have actually come across some routers which defy this rule. Some older Engenius routers (I stopped using the damned things, so I cannot speak about newer units,) some Belkin, and a couple of D-Links were culprits in breaking Windows Server DNS services.
Now that really sounds scary.
I'm surprised that anybody would be so reckless as to muck with DNS queries within a gateway router. There's little to be gained, but it doesn't take much and possibly the most important service your local network needs will suffer from it.
DNS is surprisingly brittle. Let's say you have three DNS servers in your network for redundancy, in case one of them should fail. The way you set up the client computers which rely upon the DNS services is to enter the IP addresses of the DNS servers in a configuration file. Problem is, the DNS queries are usually made in exactly the order you entered them.
If the first server should become unavailable, the query will time out and the next server will be used. Because so many services which perform DNS queries do not cache the results, having the query time out because of a failed server will mean that they will repeat the queries over and over again. Net effect: the entire client network will become stuck because the first DNS server became unavailable. How do you avoid that? I'm not sure that this is a solved problem :(
Anyway, so far I've been lucky with my choice of gateway routers at home, and even rolled my own OpenBSD-based firewall/PPPoE solution when the old gateway router I was using at the time failed.
I don't know about the Belkin gear, but I know of at least one D-Link router which we ended up replacing at my company. I wouldn't buy one of these again. Same goes for Linksys gear.
I used to use NetGear and ZyXEL gateway routers, which at least 4-6 years ago used to be quite decent. The German-made Fritz!Box routers (don't laugh, it's the actual brand name), which run on Linux are very decent, too.
I was able to show that the routers were intercepting DNS packets. I some cases the inbound was blocked, forcing the server to use the router for DNS. In other cases, outbound DNS packets were being usurped, and this caused huge issues with EDNS queries as none of these routers support EDNS so queries would be delayed, broken in sequence, or in most testing simply dropped.
It's easier to tell what's happening with your queries if you have access to an outside DNS server's logs. But it's not impossible otherwise.
True horror stories... You have to be able to trust your gateway router to do what it's supposed to. Kudos for actually proving what was going on. That must have been a real nightmare, both figuring out that the router was up to no good, and finding a remedy for the problem (before tossing out the gear, I suppose).
-
You can't trust propietary stuff. Add to the mix the mandatory US goverment mandated backdoor.
-
You can't trust propietary stuff. Add to the mix the mandatory US goverment mandated backdoor.
Not sure if there is such a thing.
From what I gather, in most cases it would be unnecessary because the lack of robust security in the firmware is a perfectly adequate substitute which also provides for convenient plausible deniability: hey, that was a bug/typo/manufacturing test.
Getting a useful backdoor into the code which is not easily discovered or used by other people who are up to no good (poster child: wiretapping functionality in Ericsson switches used by Vodafone in Greece enabled and used by persons unknown; discovered by accident in 2006) is difficult. The complexity of the task will almost inevitably lead to the backdoor being discovered.
-
Case in point: If you can't inspect it - you can't trust it.
-
@Olsen
Installed Roadshow Demo.
Wow, wow, wow, and wow. 350,000 cps peek and always above 300,000.
Ok, so now I need to test smb shares on the nas and samba. Assuming those work, and you have yourself another customer. Don't know what Easynet is having trouble with but, it simply will not perform, was just going to use Miami and hang out at 200,000. Not any more, your product screams...
-
@Olsen
Installed Roadshow Demo.
Wow, wow, wow, and wow. 350,000 cps peek and always above 300,000.
Would that be local network traffic or internet traffic?
I still think that this figure is too low for the X-Surf 100.
I can get that much out of plain Ariadne on a foggy day with drizzle and light snow (in fact, in my tests Roadshow squeezes as much out of the Ariadne as you possibly could expect from a 10 MBit/s Ethernet card: more than 900,000 bytes per second).
The X-Surf 100 should peak somewhere above 2.2 MBytes per second, and unless your internet connection is very poor in terms of throughput, you should be able to get at least 1.5 MBytes per second downstream traffic out of it, probably more.
Ok, so now I need to test smb shares on the nas and samba. Assuming those work, and you have yourself another customer. Don't know what Easynet is having trouble with but, it simply will not perform, was just going to use Miami and hang out at 200,000. Not any more, your product screams...
Well... I still think there's something fishy going on. It's nice to read that Roadshow performs better for you than both Miami and AmiTCP do under the same circumstances, but the throughput figures are far from what the X-Surf 100 is capable of.
Incidentally, the Roadshow "DEVS:Internet/servers" contains ready-made entries for smbd and nmbd, which are commented out. If you have everything installed in Samba:, then everything you need to do in order to give Samba a spin is to remove the leading '#' characters in the last three lines of the file.
-
Would that be local network traffic or internet traffic?
Internet - downloading from Aminet with Ibrowse reporting the cps. Was only getting 155,000 constant from the Ariandne, so doubling was a good test for me.
I have yet to test locally across my network, I will look up the test you recommended earlier. Would you tell me exactly what your test is so I can simulate it?
Copying across my LAN with Roadshow sucks all the life out of my cpu :), So I hope to see some large numbers (At least the music doesn't skip, but she doesn't have anything left over). I have a gigabit network with Cat 5e factory crimpled, so I should be decent speed here...
Can't understand what is fishy with EasyNet either, so if we can make roadshow work I'll go with you and support your efforts...
Thanks again for all the help and patience.
-
Did a bit more work to test it properly.
Switched to FTP using my NAS in my LAN.
Much different story.
Miami with SANA - 900,000 cps
Roadshow demo - 1,200,000 cps
EasyNet - -1,500,000 cps
Seem like with FTP EasyNet is the fastest.
That still seems slow for a 100mb NIC in a Lan.
Easynet has to have some issues, perhaps it is in the dns setup. It is a bit convoluted to my thinking.
Any ideas???
-
Memory access and CPU cycles can also limit these things.
-
Did a bit more work to test it properly.
Switched to FTP using my NAS in my LAN.
Much different story.
Miami with SANA - 900,000 cps
Roadshow demo - 1,200,000 cps
EasyNet - -1,500,000 cps
Seem like with FTP EasyNet is the fastest.
Out of the box Roadshow is configured to use resources conservatively, like it used to be back in 1995 when the 4.4BSD TCP/IP stack was released which Roadshow is based upon.
You can tweak the performance further if you would want to. Ask me how :-)
That still seems slow for a 100mb NIC in a Lan.
Yes and no.
No, because your Amiga's CPU has to do most of the heavy lifting when moving data between the network and your computer. This causes so much load that the amount of data that can be transferred will be limited by it. This is one reason why the 100 MBit/s NIC will only deliver a fraction of the theoretical bandwidth possible.
Yes, because you are still below the 2 MByte/s which the X-Surf 100 should be able to deliver on your system (provided that you have proper Cat 5 cabling, an Ethernet switch which is fast enough, supports bidirectional traffic, and the server you are testing with can send/receive data fast enough).
Easynet has to have some issues, perhaps it is in the dns setup. It is a bit convoluted to my thinking.
Any ideas???
Even if the DNS setup may look convoluted (I have no idea if it does; I never used EasyNet), it is unlikely to be the reason why the available network speed is not as high as expected.
The DNS servers configured are typically consulted once before a connection is established, and once the connection has been established, and data is being exchanged, the DNS server configuration is completely irrelevant.
Picture it like this: DNS is like a map you consult at the beginning of a road trip. You figure out where you want to go (and maybe take notes). While you are on the road, you will follow the route suggested by the map. And while you are traveling to your destination, it no longer matters how long you looked at the map, how many times you looked at it, or if you checked several maps instead of just one. What matters is the distance you need to travel, and possibly if there is construction work, detours, or if you run out of gas.
-
Man this site is terrible lately. It took me 7 times of logging in to get here...
@Olsen
Please share the speed tweaks for Roadshow! I already greatly increased the buffers. If I get it to perform beyond or even the same as EasyNet, I will pick it up.
Thanks for the great information. I going to conduct some more tests to make sure something isn't wrong in my network. I need to rule out every possible other component to point blame at the X-Surf or the TCP/IP stack.
My gut tells me that is where the issue is, but I need to prove it.
-
Follow up.
Tried FTP - NAS to my Windows PC and easily hits 20mb/s.
This is definitely an issue with my system, the card or the stack.
The best I can get with Easynet and FTP is 41Kbyte/s.
I connected my amiga to the nas on the same switch and disconnected everything else, just to make sure.
I'm willing to tinker more if anyone has ideas???
Matt
-
20 Mbit/s on a local LAN seems slow.
-
20 Mbit/s on a local LAN seems slow.
Great point... must be an issue with the qnap nas. That being said the xsurf should still see the same speed.
I will ftp to the pc and see if there is a difference. Will also use a different switch.
Appreciate the help.
-
A speed tip is to use a network card built for 1 Gbit/s on a 100 Mbit/s network in order to maxout capacity. Or 10 Gbit/s on 1 Gbit/s network etc.
-
Man this site is terrible lately. It took me 7 times of logging in to get here...
@Olsen
Please share the speed tweaks for Roadshow!
You can try three things (in order of how likely each change will land you in hot waters):
1) Change how much data may be sent in a single Ethernet packet
2) Change the number of I/O requests which the network interface uses
3) Increase the sizes of the TCP transmission buffers
The first is easy enough. Before you start Roadshow, enter the following command in the shell: RoadshowControl set tcp.mssdflt = 1500
You can make this tweak permanent with the following command, entered in the shell: RoadshowControl save set tcp.mssdflt = 1500
The default for this setting is 512 bytes, by the way. Which is how this used to be in 1995's Internet.
The second involves changing the network interface configuration file which you set up for the X-Surf 100. Let's say the configuration file is in "DEVS:NetInterfaces/X-Surf-100". Then you would open it in your text editor of choice and look for the following lines:
#iprequests=32
#writerequests=32
Remove the # characters and increase the numbers a bit, say by 16:
iprequests=48
writerequests=48
Save the changes back to disk and restart Roadshow (or your Amiga - whatever is more convenient).
Word to the wise: this tweak may not make much of a difference with the X-Surf 100. Even pumping up the numbers to 64 and beyond may not make a difference, performance-wise. It will just consume memory that might be put to better use.
The default values for the I/O requests are 16 each. Each I/O requests consumes 1500 bytes.
The third involves increasing the TCP receive and send buffers. To try this, enter the following commands in the shell before you start Roadshow:
RoadshowControl set tcp.recvspace = 65536
RoadshowControl set tcp.sendspace = 65536
The default values for both buffers are 32768 bytes, by the way.
To make these tweaks permanent, use the following commands:
RoadshowControl save set tcp.recvspace = 65536
RoadshowControl save set tcp.sendspace = 65536
Word to the wise: dialing up these buffers is not recommended unless you have far too much otherwise unused memory available. If you increase the buffer sizes, then each single network connection which your Amiga opens will eat up that much memory, e.g. if you pick 65536 for sending and receiving data, that will commit 128 KBytes to each connection.
Note that increasing these sizes will probably make no difference at all with the X-Surf 100.
Note, too, that increasing these sizes beyond a certain point will render your TCP/IP stack "combat ineffective" because it will consume so much memory that it won't be able to do anything at all. Remember: you're playing with fire if you tweak these two settings. You have been warned!
In case you do get yourself into trouble because you used RoadshowControl save set for any of these settings, you can remove these changes again with the following shell command: Delete ENVARC:Roadshow ALL
Reboot your Amiga after you have deleted these environment variables.
-
Great point... must be an issue with the qnap nas.
Um, not really.
The problem is that the X-Surf 100 is so fast that your Amiga will spend almost all CPU time just to feed new data to the card, or transfer data from the card to the TCP/IP stack.
If your Amiga were faster, then the transmission speed would be higher.
The X-Surf 100 is literally waiting for the Amiga to catch up to what it is doing, while the Amiga is already running at full tilt.
-
The first is easy enough. Before you start Roadshow, enter the following command in the shell: RoadshowControl set tcp.mssdflt = 1500
You can make this tweak permanent with this command, entered in the shell: RoadshowControl save set tcp.mssdflt = 1500
The default for this setting is 512 bytes, by the way. Which is how this used to be in 1995's Internet.
Could this method be used to set up jumbo frames? How would Roadshow, or a 50MHz 68060 Amiga, react to frames up to 9000 bytes?
-
Could this method be used to set up jumbo frames? How would Roadshow, or a 50MHz 68060 Amiga, react to frames up to 9000 bytes?
No, this tweak has a different purpose.
It changes what is known as the "TCP maximum segment size". A TCP segment may become as large as the IP datagram permits, which it fits into. The IP datagram's size is limited by the frame size of the transmission medium, and by the maximum datagram size the intermediary systems in the Internet are required to support. If I remember correctly, that maximum datagram size was 536 bytes in 1995. Which is why Roadshow has that curious 512 byte limit for the TCP maximum segment size.
In this case, the transmission medium is Ethernet, which supports frames of up to 1500 bytes in standard mode (no jumbo frames). By tweaking how large a TCP segment may become, the TCP/IP stack will make better use of what Ethernet can do. Even if you transmit less than 1500 bytes per frame, Ethernet will still spend as much time to transmit the data as if it were 1500 bytes in size. So, why not use that time to send data instead of filler?
Jumbo frames are a different matter. The network interface has to support them, and the driver, too. If you can get both to work together, the next step would be to dial up the TCP maximum segment size.
I do not know if there is an Amiga Ethernet card which supports Jumbo frames.
-
I don't recall any 512 byte limit on IP packets in 1995. Perhaps for modem users, but certainly not for Ethernet connections routed to the backbone. I think this is a misunderstanding.
Anyway, looking at TCP traffic a packet limit at 1400 .. 1420 bytes could be worthwhile to try.
-
Um, not really.
The problem is that the X-Surf 100 is so fast that your Amiga will spend almost all CPU time just to feed new data to the card, or transfer data from the card to the TCP/IP stack.
If your Amiga were faster, then the transmission speed would be higher.
The X-Surf 100 is literally waiting for the Amiga to catch up to what it is doing, while the Amiga is already running at full tilt.
Still an CS MKIII 060 @ 50MHz and 128MB of local ram, should produce much better results. At least what your Warp Engine 040 @40MHz is giving you. This performance is dismal.
Could AMFTP and Ibrowse be lying to me, can't see where that would be possible so again I go back to the hardware.
I tried booting as vanilla as possible, thinking it was my hacks, to make it go faster and it made no difference. Wonder if the X-Surf is Defective? Nothing else could explain for it at this point.
Could you PM for the speed test you created? What do I need for the other system?
-
A speed tip is to use a network card built for 1 Gbit/s on a 100 Mbit/s network in order to maxout capacity. Or 10 Gbit/s on 1 Gbit/s network etc.
Interesting point, is it possible my GB Network is the culprit? I suppose could use a cross over cable for testing.
I'm using all Intellinet Switches and Router, don't know of any issue with them.
-
Interesting point, is it possible my GB Network is the culprit? I suppose could use a cross over cable for testing.
I'm using all Intellinet Switches and Router, don't know of any issue with them.
I have good results with Intellinet switches. I was running a gigabit switch on the back-end of my virtualization platform on which I provide hosting. That said, I have never had one fail full-out, rather they tend to die a little piece at a time.
-
I don't recall any 512 byte limit on IP packets in 1995. Perhaps for modem users, but certainly not for Ethernet connections routed to the backbone. I think this is a misunderstanding.
No, this is not a size limit on packets (actually, IP datagrams). It has something to do with how the TCP protocol works, specifically how it deals with lost data or data which does not arrive in the exact order in which it was sent. There has to be a minimum required fragment size for all intermediary systems which carry TCP traffic for the protocol to work (same goes for UDP, too).
The conservative minimum requirement was 536 (or 576, I don't remember at the moment) bytes. If IP datagrams were larger than this, then intermediary systems could break them up, if necessary, thereby increasing the overhead for transport. The minimum requirement controls how small a fragment may become during transit, worst case.
The TCP/IP stack which Roadshow is built upon was released as part of 4.4BSD-Lite2 in 1995, and in that year the infrastructure that made up the Internet looked different from how it is today.
I'd say that you can use 1500 TCP segments today and won't have the individual IP datagrams broken up during transport.
But then tweaking this parameter in the Roadshow configuration isn't such a big deal. When establishing a TCP connections both peers will negotiate the maximum allowed segment size and settle on the lower value of both sides. If you allow 1500 byter per segment and your peer insists on 576 byte, then it will be 576 bytes.
I recently checked out how large that maximum segment size value actually is in practice, and I found that in my tests that 1500 bytes were accepted without complaining.
Anyway, looking at TCP traffic a packet limit at 1400 .. 1420 bytes could be worthwhile to try.
It's probably not worth the effort. The relevant protocols for data transport negotiate the parameters they need. It's just that today, you remove some of the restrictions of the past decades and not have them degraded again. Pick the largest number that works (say, 1500 bytes), and the TCP protocol negotiation will adjust to it.
-
Update for the group:
Using the tools that Olsen recommended my speed is where it should be:
Tcpspeed results:
Miami - 1,280 MB Per Second
Easynet - 2.185 MB Per Second
Roadshow - 2,066 MB Per Second
Interesting that Ibrowse can barely get 80,000 downloading with easynet, and roadshow cranks out 350,000 cps.
Thanks again Olsen. Good call on the 2.2 max for the card in my system. You were spot on!
-
Nice performance! Are there any updates for this card as far as if the module to activate the USB ports has been released yet, or an ETA? "Two more weeks"? :juggler:
-
Update for the group:
Using the tools that Olsen recommended my speed is where it should be:
Tcpspeed results:
Miami - 1,280 MB Per Second
Easynet - 2.185 MB Per Second
Roadshow - 2,066 MB Per Second
This about matches the performance figures reported by Jens Schönfeld an others. Good :)
I hope you can finally stop worrying about the hardware being defective, or your network settings to be the source of trouble. Your "X-Surf 100" seems to be working exactly as it should do.
Interesting that Ibrowse can barely get 80,000 downloading with easynet, and roadshow cranks out 350,000 cps.
Glad to hear that all the hard work I put into making Roadshow does make a difference :)
Thanks again Olsen. Good call on the 2.2 max for the card in my system. You were spot on!
2.2 MBytes/s is at the top end of the scale, for a "real" Amiga with 68060 CPU. I would expect that if you could make the 68060 go faster (hypothetically speaking!), then the throughput would increase further.
-
This about matches the performance figures reported by Jens Schönfeld an others. Good :)
I hope you can finally stop worrying about the hardware being defective, or your network settings to be the source of trouble. Your "X-Surf 100" seems to be working exactly as it should do.
Glad to hear that all the hard work I put into making Roadshow does make a difference :)
2.2 MBytes/s is at the top end of the scale, for a "real" Amiga with 68060 CPU. I would expect that if you could make the 68060 go faster (hypothetically speaking!), then the throughput would increase further.
It sounds as if we need a ethernet card with onboard cpu with large buffers to take the load off the 68060-i guess it would dma or take advantage of fast scsi when saving.
I have been following this thread and it has been interesting. i have not gotten a new x-surf card yet,but probably will soon.
-
Some other testing items, so others can save the headaches...
I increased iprequests to 77 for Roadshow and used all the other tweaks Olsen recommended, and Ibrowse really flies (relatively speaking), I went from 350,000 to over 800,000. I will try increasing more to see if I keep gaining. The tweaks don't make a real difference outside of Ibrowse 2.4.
I still can't get roadshow to beat easynet with tcpspeed and ftp. Any ideas or suggestions?
Olsen, Did you ever add in lpr.device settings to roadshow? If roadshow works with my network printer I will pull the trigger on it.
Thanks to everyone for the help...
-
It sounds as if we need a ethernet card with onboard cpu with large buffers to take the load off the 68060-i guess it would dma or take advantage of fast scsi when saving.
I have been following this thread and it has been interesting. i have not gotten a new x-surf card yet,but probably will soon.
Let us know if you pull the trigger! Even with the cpu pegged, the miggy is multitasking great.
My hacks list that I have had the best luck with:
1. Executive - seems better overall when multitasking while playing mp3's, accessing the network, and other misc stuff.
2. Quickrom - seems to give a bit of performance in general.
3. Quantum - went back to using it after commenting it out 10 years ago. Seems stable, not performance impressions yet.
4. Using P5 060 Libs.
5. Using Oxypatcher
These hacks 'feel' faster, but I don't have any numbers to back it up...
What do you use for hacks?
-
The lpr.device works with every stack but AmiTCP v3. In the case of Roadshow, it works great and switching printers is as simple as changing the ENV variables.
-
Some other testing items, so others can save the headaches...
I increased iprequests to 77 for Roadshow and used all the other tweaks Olsen recommended, and Ibrowse really flies (relatively speaking), I went from 350,000 to over 800,000. I will try increasing more to see if I keep gaining. The tweaks don't make a real difference outside of Ibrowse 2.4.
I still can't get roadshow to beat easynet with tcpspeed and ftp. Any ideas or suggestions?
Sorry, no. I still do not understand how these results come together.
Olsen, Did you ever add in lpr.device settings to roadshow?
I had not used "lpr.device" in years, so I went back to the documentation and found that you do not need to configure the TCP/IP stack to support "lpr.device" functionality.
All you need to do is set up the printer preferences to use "lpr.device" in place of "parallel.device" and set the environment variables which enable "lpr.device" to find the printer it should be talking to. That's pretty much it.
Roadshow will carry the data to the printer, but there is nothing in Roadshow which needs to be set up specifically for "lpr.device".
-
Just some follow up to share:
1. Changes the requests in the x-surf-100 dev file - seemed to give a boost, still looking for the best number. Currently using 77 and see a bit of an increase of 32.
2. Like you said in your warning, I also don't recommend changing the buffers to 65536. It created issues with copying large files accross the network. The transfer would lock. The default 32768 works perfectly.
You can try three things (in order of how likely each change will land you in hot waters):
1) Change how much data may be sent in a single Ethernet packet
2) Change the number of I/O requests which the network interface uses
3) Increase the sizes of the TCP transmission buffers
The first is easy enough. Before you start Roadshow, enter the following command in the shell: RoadshowControl set tcp.mssdflt = 1500
You can make this tweak permanent with the following command, entered in the shell: RoadshowControl save set tcp.mssdflt = 1500
The default for this setting is 512 bytes, by the way. Which is how this used to be in 1995's Internet.
The second involves changing the network interface configuration file which you set up for the X-Surf 100. Let's say the configuration file is in "DEVS:NetInterfaces/X-Surf-100". Then you would open it in your text editor of choice and look for the following lines:
#iprequests=32
#writerequests=32
Remove the # characters and increase the numbers a bit, say by 16:
iprequests=48
writerequests=48
Save the changes back to disk and restart Roadshow (or your Amiga - whatever is more convenient).
Word to the wise: this tweak may not make much of a difference with the X-Surf 100. Even pumping up the numbers to 64 and beyond may not make a difference, performance-wise. It will just consume memory that might be put to better use.
The default values for the I/O requests are 16 each. Each I/O requests consumes 1500 bytes.
The third involves increasing the TCP receive and send buffers. To try this, enter the following commands in the shell before you start Roadshow:
RoadshowControl set tcp.recvspace = 65536
RoadshowControl set tcp.sendspace = 65536
The default values for both buffers are 32768 bytes, by the way.
To make these tweaks permanent, use the following commands:
RoadshowControl save set tcp.recvspace = 65536
RoadshowControl save set tcp.sendspace = 65536
Word to the wise: dialing up these buffers is not recommended unless you have far too much otherwise unused memory available. If you increase the buffer sizes, then each single network connection which your Amiga opens will eat up that much memory, e.g. if you pick 65536 for sending and receiving data, that will commit 128 KBytes to each connection.
Note that increasing these sizes will probably make no difference at all with the X-Surf 100.
Note, too, that increasing these sizes beyond a certain point will render your TCP/IP stack "combat ineffective" because it will consume so much memory that it won't be able to do anything at all. Remember: you're playing with fire if you tweak these two settings. You have been warned!
In case you do get yourself into trouble because you used RoadshowControl save set for any of these settings, you can remove these changes again with the following shell command: Delete ENVARC:Roadshow ALL
Reboot your Amiga after you have deleted these environment variables.
-
Nice work on that Matt. It seems you stumbled on the ideal settings. Have you tried amitrade center for ftp. I dont know if its any better/faster than amftp or amiftp etc.
i was wondering are you using the MKIII scsi on your system? good scsi over ide would probabaly make a difference in speeds you see. assuming you are testing transfers to drives and not to ram.
-
Even a broken clock is right twice a day:).
Yes, using the SCSI to Acards SCSI to SATA converter and a SATA SSD.
I will try Amitrade, I think I had trouble with it though.... Will let you know.
As a quick update, if I copy huge files from my network it will still lock up occasionally on big files only. This isn't frequent, and I not sure if is roadshow or some other program like executive or smbfs.
Will keep you posted.
Matt
Nice work on that Matt. It seems you stumbled on the ideal settings. Have you tried amitrade center for ftp. I dont know if its any better/faster than amftp or amiftp etc.
i was wondering are you using the MKIII scsi on your system? good scsi over ide would probabaly make a difference in speeds you see. assuming you are testing transfers to drives and not to ram.
-
Even a broken clock is right twice a day:).
Yes, using the SCSI to Acards SCSI to SATA converter and a SATA SSD.
I will try Amitrade, I think I had trouble with it though.... Will let you know.
As a quick update, if I copy huge files from my network it will still lock up occasionally on big files only. This isn't frequent, and I not sure if is roadshow or some other program like executive or smbfs.
Will keep you posted.
Matt
If you have trouble with amitrade center its usually a missing or wrong mui lib.(or so memory thinks ;) so check the docs if this is the case.
i was working with rc-ftpd with someone who had problems with large files also,it ended up being something in the unofficial boing bags 3&4 causing it, dropping back to original BB1/2 solved it, never did figure out what it was. Not sure if this applies to you or not. It could also be something with the filesystem you are using also.
-
If you have trouble with amitrade center its usually a missing or wrong mui lib.(or so memory thinks ;) so check the docs if this is the case.
i was working with rc-ftpd with someone who had problems with large files also,it ended up being something in the unofficial boing bags 3&4 causing it, dropping back to original BB1/2 solved it, never did figure out what it was. Not sure if this applies to you or not. It could also be something with the filesystem you are using also.
Will look at the MUI Libs, but I think it 80000004'ed before it even got to that point. Thanks...
I have BB2, had issues with BB4 and my Delfina setup...
Thanks for the suggestion, I used FTP to copy the entire file over. Has to be SMBFS limitation somewhere... Man I wish someone would update SMBFS to modern levels... Getting more limiting as time goes on. Would be a great additional bonus if someone fixed the filesystem to work with large files...
-
My results with my new X-Surf 100.
A3000 WB3.9 BB4
Cyberstorm 68060
Genesis
Ibrowse http transfer.
I average about 750,000 cps.
I must open 3 concurrent transfers to reach the max transfer.
Going to try FTP to see if that moves faster, each IBrowse network process is using 7-9% of my CPU (3x), but once all processes reach 95% it peaks.
Shame it doesn't offload the checksum to the card as stated earlier, that seems to be the achilles heal of it all.
-
A base and random file transfer rate in cps is not a fair way to evaluate NIC card transfer speed, one needs to control all the hundreds of other variable factors that impact that number. I would go with the card's designer recommendations that AmiTCP with his tweaks gives the best performance. His testing was in a controlled environment setting where he limited the random variables.
-
The catch is that real life usage isn't laboratory conditions.. ;)
-
The catch is that real life usage isn't laboratory conditions.. ;)
In that case, numbers mean nothing and you should go with intuition on TCP stack decisions and not bother quoting any numbers.
-
It means one should try a variarity of situations to test. Even the Monty carlo method comes to mind.
-
It means one should try a variarity of situations to test. Even the Monty carlo method comes to mind.
And your validity comes from where? A guess? A feeling?
You can't account for the hundreds of variables that affect performance that way.
-
I ran some tests with tcpspeed as my x-surf100 is up and running in z3 mode.
Genesis 849 kb/s
RoadShow 685 kb/s
Miami 422 kb/s
Roadshow is configured with the suggestions earlier in the thread. (Which made a little speedup) I was hoping for higher transfer rates though as i see the results of other users.. However, i have some limitations in my system:
Im using an a4k/a3660/50mhz which is practically running on zIII memory (FastlaneZ3) as my 8mb on the mb is eaten up by the os.
Will the zIII mem performance affect the transfer rates this much?
I knew genesis could be faster than roadshow, but not that much.. and Miami?! come on!! :)
Cheers!
-
I knew genesis could be faster than roadshow, but not that much.. and Miami?! come on!! :)
Nice tests! Miami's always been a dog, but what it lacks in speed it makes up for with a nice GUI, unlike Roadshow. Too bad Holger K. had to be such a (%*#&%*%&$#?@!%&$#?@!%&$#?@!$% and abandon it. :(
-
I ran some tests with tcpspeed as my x-surf100 is up and running in z3 mode.
Genesis 849 kb/s
RoadShow 685 kb/s
Miami 422 kb/s
Roadshow is configured with the suggestions earlier in the thread. (Which made a little speedup) I was hoping for higher transfer rates though as i see the results of other users.. However, i have some limitations in my system:
Im using an a4k/a3660/50mhz which is practically running on zIII memory (FastlaneZ3) as my 8mb on the mb is eaten up by the os.
Will the zIII mem performance affect the transfer rates this much?
I knew genesis could be faster than roadshow, but not that much.. and Miami?! come on!! :)
Cheers!
I could get more than 900 KByte/s out of Roadshow on an original "Ariadne" card (Zorro II, 10 MBit/s Ethernet, no full-duplex support), on my A3000UX with a 50 MHz 68060 CPU.
I would expect the XSurf-100 to do much better by comparison.
-
I could get more than 900 KByte/s out of Roadshow on an original "Ariadne" card (Zorro II, 10 MBit/s Ethernet, no full-duplex support), on my A3000UX with a 50 MHz 68060 CPU.
I would expect the XSurf-100 to do much better by comparison.
Agree! I will see what I can get on mine when I get home this weekend. I wass using a PCI 8139 with my mediator before the x-surf 100 came out. I replaced it and the x-surf was noticeably faster stock using roadshow over the PCI card.
I havent even tried any of these settings changes yet, looking forward to testing this all out.
-
Nice tests! Miami's always been a dog, but what it lacks in speed it makes up for with a nice GUI, unlike Roadshow.
Don't think I've ever felt the need for a Roadshow GUI. But we're all different :)
-
Don't think I've ever felt the need for a Roadshow GUI. But we're all different :)
I'm not.
-
10Mb/s is roughly 1MB/s, so 900k BYTES per second is really not bad.