OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Hardware => Topic started by: Dariusz Piatkowski on February 05, 2015, 02:11:30 pm
-
Folks, I've got a RealTek RTL8111DL on-board network chip...currently using a 3Com 3c905B NIC but that's only 100 speed, with a lot more media floating around the house I'm trying to get the motherboard chip running to use it's 1000 mode.
Well, after a bunch of looking around I found r8169100.zip which is David's BETA release of the chipset driver. Install went smooth, my problem is that as soon as I attempt to do a PC to PC FTP xfer the whole PC locks hard...so I'm curious if anyone else has tried these?
Thanks!
-
I've been using this driver for years. It's fantastic. Early on, I reported some problem with Virtual PC, but David fixed it. Realtek hardware is pervasive, and to have a reliable driver is extra good.
I do have a network problem that causes NetBIOS to die after a long time (17 days was the shortest run time, 3 months was the longest) with a related MultiMac driver, the e1000e. I have not had the patience to chase down a reliable recipe to reproduce this bug.
I don't know why you had to chase this driver down. It's a standard Arca Noae product.
The 3c905B hardware and driver are the only really reliable NetBIOS hardware that I know.
-
I found r8169100.zip which is David's BETA release of the chipset driver
The beta driver has some very serious problems, depending on which Realtek chip you actually have (RTL8111DL doesn't tell you that). The proper driver works well, and you can get it (with support) from Arca Noae: https://www.arcanoae.com/about/ (https://www.arcanoae.com/about/)
If you don't want to pay for Multimac, you should try the GENMAC driver. Again, depending on the exact chip, it may, or may not, work (and there is no support). There is another, older, driver rtgnda13.zip which will probably work, but I don't think it works with NETBIOS (I think it was okay with NETBIOS over TCPIP).
The main problem that I see, with Realtek NICs, is that they are SLOW (even in windows, they are much slower than Intel NICs). This seems to be a known drawback with them, on all platforms, but it seems that they are cheap, so manufacturers keep on using them. FWIW, I would not be surprised if your 100 mbs 3c905B would be just as fast as a 1000 mbs Realtek device.
You may also find that NETBIOS will not work with a lot of other things, like routers, and WiFi devices, that don't know about it. NETBIOS over TCPIP usually works with them.
NETBIOS also has a number of limitations that make it unusable with other operating systems. The fix for that is to abandon NETBIOS and use SAMBA (which is effectively the same as NETBIOS over TCPIP, with support for large files, and modern security).
-
I found r8169100.zip which is David's BETA release of the chipset driver
The main problem that I see, with Realtek NICs, is that they are SLOW (even in windows, they are much slower than Intel NICs). This seems to be a known drawback with them, on all platforms, but it seems that they are cheap, so manufacturers keep on using them. FWIW, I would not be surprised if your 100 mbs 3c905B would be just as fast as a 1000 mbs Realtek device.
They are in no way slower than the Intel Nics, they do have a very conservative handshake implementation and need to have their settings tweaked to force them to connect to switches at full speed, but that is something you should do to any NIC any-ways.
-
And from what I can tell from the Roadmap of AN they write this: https://www.arcanoae.com/roadmap/
New Ethernet and Wireless network drivers
"With the aid of the MultiMac framework, Arca Noae already provides support for some Intel, Nvidia, and Realtek chipsets based on Linux drivers. Changes in the Linux driver architecture have made maintaining these drivers and porting new drivers increasingly difficult. As was announced at Warpstock 2014, Arca Noae is working on an alternative new library for porting FreeBSD drivers to OS/2. Initially we expect several new ethernet drivers to be produced by this new approach. Wireless drivers will follow after the first few ethernet drivers, but may take a bit longer due to the increased complexity of wireless drivers."
Roderick Klein
-
There is another, older, driver rtgnda13.zip which will probably work, but I don't think it works with NETBIOS (I think it was okay with NETBIOS over TCPIP).
RTGNDA speed highly depends on CPU frequency...
I saw 40mb/s from w2k3 server with pure NETBEUI. NETBEUI works, but only as client.
Another (solvable) trouble - this driver often sets zero MAC. This can be fixed by manual setting of NETADDRESS option.
-
They are in no way slower than the Intel Nics, they do have a very conservative handshake implementation and need to have their settings tweaked to force them to connect to switches at full speed, but that is something you should do to any NIC any-ways
Please educate us. What, exactly, will make them run better?
Everything that I have tried makes them worse, not better (I don't remember what I tried, but the defaults were best). I see performance of Realtek 1 GB NICs at about 70% of what I see with Intel in windows 7, Linux Mint 17.1, and they run at about 50% in eCS. I have one NVIDIA NIC, that runs great with Multimac (even faster than Intel, and faster than it runs in WinXP).
-
I've been using this driver for years. It's fantastic...I don't know why you had to chase this driver down. It's a standard Arca Noae product...
Hmm...great point...LOL...I bought the Arca Noae drivers package and simply forgot they have the NIC stuff included in that.
I pulled the latest version, plugged in the R8169 driver (following a WarpIn re-install over the previous version I found). Attempted to boot, but this time around my system actually hangs during boot-up right after the driver report it's status (using the /V CONFIG.SYS driver parameter). Not even CTL-ALT-DEL works, instead I have to do CTL-ALT-NUMLCK twice...grrhh...nothing like a massive CHKDSK run against my 14 HPFS386 partitions...LOL...yeah, that hurts!!!
Sooo....given that this approach to driver development is a dead-end, and that new roadmap has been identified (as also stated in this thread by other posters) I might post a quick bug report, but if no konwn solutions exist I'm most likely going to give up the chase here. Seems like a much more proven way is to simply pick up an Intel Pro 1000 NIC and use the original Intel drivers.
As far as my needs go I'm only looking for TCP/IP...no NetBIOS, etc...
Doug: PCI hardware report actually shows 10EC:8168h, so that's RealTeak 8168 cihpset. The motherboard manuals claims it to be the RTL8111DL.
-
...The main problem that I see, with Realtek NICs, is that they are SLOW (even in windows, they are much slower than Intel NICs)...
I was initially able to get the rtgnda.os2 driver to recognize the chipset and at least boot up in 100 mode. As you pointed out though, the FTP xfer performance was absolutely dismal between my 2 local machines, as in an order of magnitude difference. I was getting 600k instead of the typical 8Meg I'm seeing on my 3Com...I suspect there must have been something else seriously wrong here, at least in my setup. Maybe this is why I never got much further with the Arcae Noae drivers either.
-
Doug: PCI hardware report actually shows 10EC:8168h, so that's RealTeak 8168 cihpset. The motherboard manuals claims it to be the RTL8111DL.
That still doesn't tell you which (of many) chipset you have. If you report a problem to the Arca Noae bug tracker, David A. will probably get you to run a program (can't remember what it is), to determine exactly which chipset you have. If it is one of the ones that is known to work, you need to look deeper into your own setup. If it is something new, he may be able to tweak it to make it work. It is important to have the CONFIG.SYS entries in the correct order, and it helps to use Alt-F2 so you can see exactly what it was trying to do when the problem occurred.
I was initially able to get the rtgnda.os2 driver to recognize the chipset and at least boot up in 100 mode.
Rtgnda is a last resort. It is OLD, and incomplete, but it does come with source code, if you are into things like that.
nothing like a massive CHKDSK run against my 14 HPFS386 partitions...LOL...yeah, that hurts!!!
Sounds like self inflicted pain, to me. JFS is the answer, but that could be a bit of work.
-
Rtgnda is a last resort. It is OLD, and incomplete, but it does come with source code, if you are into things like that.
And constantly trapped my system. Since removing RTGNDA this system works since years. At first with PCI RTL8139 card and now with Multimac and Realtek 81xx GBit chip.
Source code - if you really like to dig into assembler this maybe a playground for you. I checked if EOI is implemented correct for SMP but then I gave up.
-
nothing like a massive CHKDSK run against my 14 HPFS386 partitions...LOL...yeah, that hurts!!!
Sounds like self inflicted pain, to me. JFS is the answer, but that could be a bit of work.
Well, "self inflicted" or not, you have to deal with whatever technology is available at any given time. So consider that before JFS was available (and stable) to run a large partition you really had no choice and best you could do was to move to multiple HPFS386 partitions to benefit from the larger cache. There was absolutely nothing wrong with taking that direction.
I do agree, JFS is probably the answer, but before I get there I need to move the data residing across these multiple partitions to a NAS device then go re-defining my HD configuration.
-
Well, as it turns out, just when I was about to give up there came up a good forum search result...http://www.os2world.com/forum/index.php/topic,313.0.html (http://www.os2world.com/forum/index.php/topic,313.0.html) where I came across an older post of Paul Smedley's where he made a test version of a RealTek driver available.
I downloaded this file (http://smedley.id.au/tmp/r8169-3.12.8.zip), and having given it a try it turns out to work on my system. As it also happens, it is the ONLY driver that works on my MIS 880G-E45 motherboard in the 1000FULL configuration.
This is a 1Gig NIC, the driver supports this speed and shows a pretty good sustained xfer rate between my LAN PCs.
I emailed Paul asking if he might be able to release an updated version of this driver?
-
Well, as it turns out, just when I was about to give up there came up a good forum search result...http://www.os2world.com/forum/index.php/topic,313.0.html (http://www.os2world.com/forum/index.php/topic,313.0.html) where I came across an older post of Paul Smedley's where he made a test version of a RealTek driver available.
I downloaded this file (http://smedley.id.au/tmp/r8169-3.12.8.zip), and having given it a try it turns out to work on my system. As it also happens, it is the ONLY driver that works on my MIS 880G-E45 motherboard in the 1000FULL configuration.
This is a 1Gig NIC, the driver supports this speed and shows a pretty good sustained xfer rate between my LAN PCs.
I emailed Paul asking if he might be able to release an updated version of this driver?
Lets see if Paul can fix this:
"Changes in the Linux driver architecture have made maintaining these drivers and porting new drivers increasingly difficult. As was announced at Warpstock 2014, Arca Noae is working on an alternative new library for porting FreeBSD drivers to OS/2."
I understood from an IRC channel, somebody explained to me that porting sources with that Multimac skeleton is not realy anymore possible. That means the current Linux sources have changest that far is realy the question if a new port can be done that easly. Since David and Paul are using the same code skeleton you are most likely on a dead track, for now...
The only solution I think is when AN brings out the new FreeBSD drivers as annouched at Warpstock US.
Rodeick
-
...I understood from an IRC channel, somebody explained to me that porting sources with that Multimac skeleton is not realy anymore possible. That means the current Linux sources have changest that far is realy the question if a new port can be done that easly. Since David and Paul are using the same code skeleton you are most likely on a dead track, for now...
The only solution I think is when AN brings out the new FreeBSD drivers as annouched at Warpstock US.
Rodeick
Yes, you are correct. Paul did reply to my email and said that the RealTek driver was really more of a curiousity/fun thing for him as he was updating the kernel.
OK, for now, I'm going to use what I have and see where AN goes with their driver development. If anything I can contribute some testing efforts on both the 3Com and RT chipset side of things.
-
Here are measuring results with two systems using GBit Realtek chips and latest ArcaNoae drivers -
TCP
{0}[p:\util\netio123\bin] os2-i386.exe -t 192.168.1.114
NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 93590 KByte/s Tx, 113283 KByte/s Rx.
Packet size 2k bytes: 69820 KByte/s Tx, 113431 KByte/s Rx.
Packet size 4k bytes: 62117 KByte/s Tx, 97513 KByte/s Rx.
Packet size 8k bytes: 67462 KByte/s Tx, 97814 KByte/s Rx.
Packet size 16k bytes: 57835 KByte/s Tx, 114030 KByte/s Rx.
Packet size 32k bytes: 64066 KByte/s Tx, 99869 KByte/s Rx.
NETBIOS
Netbios mit Power settings auf lowest
{0}[p:\util\netio123\bin] os2-i386.exe -n NETIOSRV
NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel
NetBIOS connection established.
Packet size 1k bytes: 2518 KByte/s Tx, 4272 KByte/s Rx.
Packet size 2k bytes: 4349 KByte/s Tx, 66834 Byte/s Rx.
Packet size 4k bytes: 6067 KByte/s Tx, 8063 KByte/s Rx.
Packet size 8k bytes: 8520 KByte/s Tx, 9570 KByte/s Rx.
Packet size 16k bytes: 10436 KByte/s Tx, 10524 KByte/s Rx.
Packet size 32k bytes: 10912 KByte/s Tx, 10952 KByte/s Rx.
This all with Power settings of the ZyXEL GS1910 switch which is in between to maximum power saving (ActiPHY, PerfectReach, EEE). With standard setting (wasting most power) at least TCP is even little faster. Not tried with NETBIOS.
UDP is terrible bad. No clue if this is an driver issue or the ZyXEL slows them down. But as I hardly use UDP I do not care.
Another test transferring a 2GB file over ftp gave (Peter Moylans ftp server and Netdrive ftp plugin) an average transfer rate of about 57MByte/s. No clue if the network limits this value or the ftp software.
-
Here are my throughput numbers measured using Netio:
OS/2 machine is in CLIENT MODE
TCP connection established.
Packet size 1k bytes: 75394 KByte/s Tx, 68437 KByte/s Rx.
Packet size 2k bytes: 74959 KByte/s Tx, 93138 KByte/s Rx.
Packet size 4k bytes: 72712 KByte/s Tx, 90809 KByte/s Rx.
Packet size 8k bytes: 83003 KByte/s Tx, 85505 KByte/s Rx.
Packet size 16k bytes: 72582 KByte/s Tx, 87206 KByte/s Rx.
Packet size 32k bytes: 72901 KByte/s Tx, 85838 KByte/s Rx.
Done.
UDP connection established.
Packet size 1k bytes: 218 KByte/s (99%) Tx, 112445 KByte/s (0%) Rx.
Packet size 2k bytes: 421 KByte/s (99%) Tx, 16891 KByte/s (0%) Rx.
Packet size 4k bytes: 262 KByte/s (99%) Tx, 32807 KByte/s (0%) Rx.
Packet size 8k bytes: 353 KByte/s (99%) Tx, 60148 KByte/s (0%) Rx.
sendto(): No buffer space available
On the UDP piece above I get this "buffer space" error...not sure why...maybe because I'm only running TCP/IP setup, no Netbios, etc....
Section below is OS/2 in SERVER mode...pretty high numbers...
OS/2 machine is in SERVER MODE
TCP connection established.
Packet size 1k bytes: 112427 KByte/s Tx, 115555 KByte/s Rx.
Packet size 2k bytes: 112496 KByte/s Tx, 115362 KByte/s Rx.
Packet size 4k bytes: 114891 KByte/s Tx, 115573 KByte/s Rx.
Packet size 8k bytes: 114583 KByte/s Tx, 115275 KByte/s Rx.
Packet size 16k bytes: 114690 KByte/s Tx, 115306 KByte/s Rx.
Packet size 32k bytes: 115033 KByte/s Tx, 115549 KByte/s Rx.
Done.
-
What do you mean with
OS/2 in SERVER mode
?
-
What do you mean with OS/2 in SERVER mode
?
The NETIO EXE allows you to run in either CLIENT or SERVER mode...I assume that simply controls which side is doing the start of the sending and perhaps the controlling of the transmission.
So, in CLIENT mode on my OS/2 box I run "netio -t 192.168.1.20", but this requires a SERVER side of the app to be running on the "other" end (namely 192.168.1.20), and for me that means I run "netio -s" on that WinXP box.
Now in SERVER mode I simply switch this around.
Why do this? I took this approach to merely understand if the CLIENT/SERVER had any impact on the throughput. If the bottleneck was networking hardware (router, switch, etc) I would have expected to see a consistent throughput regardless of which side was initiating the transfer. Meanwhile, given the different results I'm thinking the software itself (driver and/or parameters such as buffer allocation) is what appears to make the difference.
Anyways, I am no networking guru...so this is pure speculation...if anything I'm simply attempting to understand the environment a little better.