I think it’s devn-ne2000.so as it’s a Corman FE122 card running at 100M.
How can I confirm the driver? - I can see no evidence of this anywhere.
FYI, the other machine uses a Corman CT-E110 10BaseT card (10M). It
doesn’t seem to have a problem.
I’m starting qnet like this:
mount -T io-net npm-qnet.so
The network is pretty small and quiet, and a switch is being used. I
can’t imagine why there would be delays of 100 mS or more. However, I’ll
try and extend the timeout as you suggest and see what happens. I
presume the ticksize argument is intended for npm-qnet.so I can’t find
I don’t think symbolic links are the problem. A [real] file of 3.5Mb
simply cannot be transferred using qnet.
I tend to favour your theory about the driver.
Xiaodan Tang wrote:
What NIC driver ? After the copy fail, does QNET still alive ? What exactly
is the error message? I also suggest try “cp -Rp /net/… ./” to eliminate
Another possiability I could think of is the nic driver drop connection.
QNET on 6.20 is sensitive for network losing. Druing transmit, a 100ms -
loos of network, will casuing QNET think the network is down. I suspect the
network driver have problem to communicate.
Try bring up QNET with this option, “ticksize=500, <… orignal option>”,
will extend the timeout up to 2.5 seconds; see if this could help you out.
Geoff <> firstname.lastname@example.org> > wrote in message
news:> 3E3246C3.5D8C3E9E@rtts.com.au> …
I’m having difficulty copying a 3.5Mb file from one machine to another.
In fact, impossible, as the sending machine loses its network. Likewise,
a recursive copy (cp -R /net/… ./) results in the same.
I was able to pax and freeze the directory tree (resulting in the above
mentioned file) and FTP it OK. But using QNET breaks the network
Does anyone else have this or similar problems? I’m using 6.2.0 and
pretty much out-of-the-box installation.
Realtime Technology Systems Pty Ltd
2 Hadleigh Circuit
Phone: 61-2-6291 3833
Fax: 61-2-6291 3838
Mobile: 0413 634 667