Gigabit ethernet?

Are there any 1000bT ethernet cards that will work with AmigaOS 4.1 update 2?

I have an 800 MHz Sam Flex.

@jbni

OS4.1u2 includes rtl8169.device, which is the only gig-e chip driver I recognize there. I haven't seen user reports on any hardware platform (SAM or not) though.

@jbni

Any Realtek 8169 card should do.
But be warned: You will not get any transferrates beyond 20MB/sec .. and those only in some very special situations. Most of the time you will very likely stay at 10-15MB/sec ..

Especially with the available public 8169 driver. My current development version is a bit faster (max. around 25MB/sec), but also only in very special situations.

This is not a problem of the driver itself, but it's caused by our current network architecture which was designed with 10Mbit or at most 100Mbit in mind. Roadshow is based on BSD4.4lite (IIRC) which was released in 1994. Also the SANA2 specification for network drivers isn't prepared for such high transferrates.

To make good use of 1Gbit we'd need a new TCP stack based on modern BSD network kernel as well as an updated SANA2 specification (or even a completely new SANA3), which are aware of such high rates and accordingly written (i.e. avoiding memcpy() whereever possible, making use of DMA capabilities of network chips, support for jumbo frames, etc. pp.).

So for now, there's (unfortunately) practically no sense in using a 1Gbit card with AmigaOS only. Of course, if you are also using Linux on the same machine then you can make good use of 1Gbit at least on Linux and it will also work - just slow - on AmigaOS.

P.S: No, we don't have the resources right now to tackle this problem.

@Cyborg

I've seen this limitation in network transfers, and wondered what caused it. Thanks very much for explaining this.

@Cyborg

10-15MB/s!! I only get around 6MB/s (50Mb/s) top speed when the CPU reaches 100% over FTP on with A1XE.

@Deniil

Okay, okay, :)
Cyborg meant Mb, not MB.

@logicalheart

Quote:

I don't think so. 6 MB/s requires at least 48 Mbit/s, so that would make Deniil's setup much faster than Cyborg's GigE one if Cyborg was managing 25 MB/s as absolute max. Plus, Cyborg's post uses both MB and Mbit very precisely.

Hans

@Hans

So we can get as high as 160 Mbps with a Gigabit card? (20 MB Cyborg reference)?

With my current 100 Mbps AmigaOne cards, on-board or PCI, I've never gotten higher than 48 Mbps, so should I be getting higher? Or do you think that is the limitation of the NIC processor?

@logicalheart

First of all: I know the difference between MB and Mb(it) very well, so you can take my figures just like I wrote them. And I also know that it should actually be "MiB" instead of "MB", but thats something I'm not able to get comfortable with :)

As I said, under very special circumstances I got a peek of 25MB/sec for raw TCP transfers with a Gbit card. "Raw" as in "no other protocol overhead like FTP, HTTP or thatlike involved" and also without using any massstorage devices but only from/to memory.

Thats very likely the best we can squeeze out of our current TCP/IP subsystem. In real usage, it boils down to 10-15 MB/sec (e.g. FTP from/to your local harddrive).

With my 100Mbit cards & drivers (the Realtek 8139 ones) I'm most of the time between 7 and 9 MB (including any overhead) and >10MB with raw TCP transfers (which are otherwise unfortunately useless ;) ).

That is on an A1 XE G4 @ 1GHz btw.

The actual transfer rates also highly depend on the other side as well as the cabling, the connection and the used software. E.g. AmiTradeCenter is slower than pFTP probably because emulated 68k vs. native PPC (or Pete's coding skills ;) ), and Samba is slower than NFS due to the massive SMB protocol overhead, etc.pp... you got the idea.

Edit: Oh and I totally forgot to mention the Roadshow settings. The stock settings are somewhat "conservative" (better safe than sorry). With more aggressive settings you should be able to get beyond your 6MB/s ... see the RoadshowControl documentation.

@Cyborg

NFS? NFS, you say?

Where might I find an NFS client for OS4?

Or server, I guess, but I really need a client.

@jbni

I use nfs client from the version of AmiTCP that was in the NetConnect 3 package. I'm fairly certain it's on Aminet.

It's 68k, but works fine here (though not fast).

@Cyborg

Got it. Thanks again for explaining.

@Cyborg

Quote:

Out of curiosity, which version of BSD would be the best to use as the starting point for an updated TCP stack? AFAIK, BSD4.4 was the end of the line for BSD itself, and it forked into FreeBSD, OpenBSD, and a bunch of others.

I'm not familiar with the BSD variants at all, so I don't know which would provide the best basis.

Hans

@ jbni

I'm using ch_nfs from the old AmiTCP package. Just download the demo from Aminet, ch_nfs is in there.

The sources for ch_nfs are meanwhile open source on sourceforge, unfortunately some important parts are lost and the project (IIRC its called aNFS) is stalled

@Hans

That very much depends on what you want to achieve. If you want an as robust and reliable as possible stack (i.e. "conservative"), you would probably choose OpenBSD. If you want the very latest and most innovative features, you'd probably choose NetBSD... and FreeBSD for something in between.

I think the OpenBSD stack would be also the one most similar to the BSDlite stack and hence to Roadshow.. but in the end of the day it probably doesn't matter which stack you choose as all changed so much since 1994 that you couldn't reuse much of Roadshow besides parts of the AmigaOS library stuff. And of course would any modern BSD stack support anything we can just dream of now..

And there's the documentation problem: None of those modern stacks is really well documented. Pretty much all books about the inner workings of TCP stacks are talking about some BSDlite version and really outdated. Again, the OpenBSD stack would probably be the "easiest" choice because of being the most similar stack to BSDlite.

You want to volunteer?

@Cyborg
Quote:

If there's a complaint that Roadshow is lacking because of its basis on BSD4.4lite, then why would we want to remain with a stack that is most similar to that lacking BSD4.4lite stack? Would not a _more_ different one be a better choice in this situation now?

Which has the best wireless networking features/support/API? Which supports the most kinds of networking (10/100Mb, 1Gb, 10Gb, fiber, Wimax, cellular w/SIM card, bluetooth tethering, etc)? Which of these and other items don't need to be in the stack itself but can remain outside in a good way?

@Cyborg

Quote:

Having never written a networking app, I'm not the right person for the job. I really hope that someone decides to take on the job though, and chooses something that can be periodically updated.

Hans

@billt

You misunderstood. Each stack of any BSD variant supports all the modern features like IPv6, net80211, Jumbo frames, etc. OpenBSD did just not change the stack as radical as eg NetBSD and has more reliability, stability and portability in mind than the others (which partly aim for the best performance and to support new standards as soon as they wer specified or even earlier as drafts).

Regardless which BSD stack would be the base, we would get any important features introduced to the world after 1994.

Your feature wish list has indeed some flaws:

Things like "Bluetooth tethering" do NOT have anything to do with the TCP stack. First you need a Bluetooth stack, then you can write network drivers which make use of some Bluetooth devices. Just like it is now already with USB. Bluetooth is just another transport media.

The rest of your feature listing are mainly driver issues and not directly related to the TCP stack itself. (besides parts of modern WiFi support which is provided by the net80211 WiFi kernel. But even then, proper drivers have to get written which make use of it)

Also You tend to forget the manpower needed to properly do a new TCP stack which also involves specifying a whole SANA API to support very high data rates, the specialities of WiFi, etc. This manpower is not available at the moment. At least not in the OS4 team as we have already many other things to do on our desks (besides having some real life and earning money).

@Hans

Actually it's on my TODO list since a couple of years already. But there are that much dependencies and pitfalls involved that my little Amiga time is not even enough for doing serious research.

I think this task would be similar enormous like doing a whole new Picasso96 replacement, which should give you an idea about it as a graphics driver guy.