X-Surf 100 - Best TCP/IP for Speed?

[danbeaver]

This just tells me that AmigaOS need a new network driver infrastructure..

It already has that in OS 4.1.

[mechy]

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?

[freqmax]

It already has that in OS 4.1.

For classic OS that is

[matt3k]

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...

[olsen]

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.

[olsen]

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.

[olsen]

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.

[freqmax]

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!

[olsen]

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?

[freqmax]

Only working on some OS versions.

I just think it would be a serious improvement to get a clean and efficient API.

[matt3k]

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.

[olsen]

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?

[olsen]

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.

[matt3k]

@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.

[matt3k]

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?

[olsen]

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.