P4BGL-MX/533 and RTL8139 and Ghost

  • Thread starter Thread starter Robert Sudbury
  • Start date Start date
R

Robert Sudbury

At work we're rolling out our first non-Intel based onboard nic mobos in
years, the Asus P4BGL-MX/533.

The latest available ndis2 driver from RealTek for the RTL8139 in DOS (3.24)
has issues... or is it the chip... or the power supplies... or mobo itself?

We use Ghost7 Enterprise for pushing the desktop images. At first I thought
the issues may be related to the 3Com 1100/3300 switches in between the
clients and the server but no.

These machines fail the ghost PUSH process either immediately or whenever,
when connected via 10Mb, full or half duplex... guaranteed. They will also
fail a manual ghost download via a DOS boot disk and the 3.24 ndis2 driver,
but uploads are okay.

When connected at 100Mb, it's a crap shoot whether PUSH will work, but
manually connecting via ndis2 driver 3.24 works up and down... though the
speed at 100Mb never goes over 200MB/min. Considering these are 1.7GHz
Celerons, we should expect considerably higher. Even attempts to push a
single client can and does fail with no other devices on the network and a
dedicated pipe from the server to that single client.

Cabling has been ruled out as a possibility. This is happening at all sites
these machines are going into, with many different network configurations,
loads etc... Meanwhile all Intel based connections fly as usual.

Does anyone have an ndis2 dos driver for this RealTek PHY that is optimized
for Ghost and works at all connection speeds?
 
"Robert Sudbury" said:
At work we're rolling out our first non-Intel based onboard nic mobos in
years, the Asus P4BGL-MX/533.

The latest available ndis2 driver from RealTek for the RTL8139 in DOS (3.24)
has issues... or is it the chip... or the power supplies... or mobo itself?

We use Ghost7 Enterprise for pushing the desktop images. At first I thought
the issues may be related to the 3Com 1100/3300 switches in between the
clients and the server but no.

These machines fail the ghost PUSH process either immediately or whenever,
when connected via 10Mb, full or half duplex... guaranteed. They will also
fail a manual ghost download via a DOS boot disk and the 3.24 ndis2 driver,
but uploads are okay.

When connected at 100Mb, it's a crap shoot whether PUSH will work, but
manually connecting via ndis2 driver 3.24 works up and down... though the
speed at 100Mb never goes over 200MB/min. Considering these are 1.7GHz
Celerons, we should expect considerably higher. Even attempts to push a
single client can and does fail with no other devices on the network and a
dedicated pipe from the server to that single client.

Cabling has been ruled out as a possibility. This is happening at all sites
these machines are going into, with many different network configurations,
loads etc... Meanwhile all Intel based connections fly as usual.

Does anyone have an ndis2 dos driver for this RealTek PHY that is optimized
for Ghost and works at all connection speeds?
Click to expand...

The Celeron has to copy the data via block move from a receive buffer
into a space the rest of the software stack can use it. It could then
be copied via DMA. The RTL8129/39 are not high performance ethernet
devices, so are probably incapable of keeping up with the data rate.

http://www.scyld.com/pipermail/realtek/2002-August/001468.html
http://www.corega.co.jp/product/os/source/rtl8139.c

You didn't mention it, but you are probably multicasting. Maybe
the source machine should have a lower performance than the destination
machine(s), so there is less chance of dropping packets at the
dest. Maybe there is a network throttling parameter in Windows
for the source machine ?

Just guesses,
Paul
 
Thanks for the links. That first one has some juicy bits.

As it happens, the source server is running slower than the client machines,
but again, there is no problem dealing with any version of Intel's 100+
NICs, or even Digital 21041, and 3Com's.

This is very obviously a RealTek issue. The problems these other people
described mirror almost exactly what we're experiencing. This gives me some
ideas about perhaps tweaking the BIOS on the mobos to see if preference can
be given to the onboard lan, irq... Though I don't remember seeing anything
useful like that in the BIOS... or maybe even the usb mouse.

Yes we are multicasting. With 80 LANs on the WAN, that's the point.
Altering the configuration of these networks when they already work
wonderfully for everything else, for what is now obviously an inferior part,
is probably out of the question.
 
Have you tried the -BUFFERSIZE=8 switch? I had that performance issue with a
different NIC and that switch resolved it.
 
Back
Top