Xiaodan,
i tried to do cp -V /net/xx/file /dev/null, the speed was 75kb/sec.
FTP speed over the same link was 500kb/sec but transfer was suddenly
interrupted after 4Mb were transfered, with ‘short write’ messages
followed by ‘remote site closed connection’.
TCP/IP to internet works perfectly on both sides. I get 250kb/sec from
tucows on Orinoco side and 400kb/sec from my ISP on 3c905 side, no
errors of any kind. Cable modem is connected to the same hub as both
sides, so link between them can’t be a problem.
Looks to me like there’s some bug either in QNET or triggered by QNET. I
could let you to login and see for yourself if that helps.
Xiaodan Tang wrote:
Igor Kovalenko <> kovalenko@home.com> > wrote:
I apologize for kinda ‘stealing’ this thread, but it is probably QNET
problem too.
I tried to make the SPIN QNET-aware and ran it between two 6.1 machines, one
over 3C905B 10Mb/sec another over Orinoco 11Mb/sec wireless (access point
connected to common hub in ‘bridge mode’).
They see each other in the /net without any efforts. Doing pidin -n xxx
works, although it is visibly slow (you can see each line being printed).
With SPIN it works too, but real slow. Screen gets refreshed only once in
9 secs, all other time it appears to be REPLY-blocked on another node’s
procnto. CPU utilisation in 50%, most of it split between procnto and
io-net. I can send a copy for testing.
Before you run the SPIN, how about “cp -V largefile /net/remote/dev/shmem”
show? My 2 mahcine hook up with 10MB ether showing upto 800KB+/s, do you
get that kind of result?
Also, is tcpip between this 2 machines reasonable? (ttcp rate?) We want to
first make sure no network driver problem involved here.
Oh, and yes, please send me the binary > 
-xtang
“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:9ihoca$mag$> 1@nntp.qnx.com> …
Dave Edwards <> dedwards@wavelength-digital.com> > wrote:
Hi,
We are trying to connect a number of QNX6.0 machines together using
QNET. Our current build is QNX6.0 Patch C (althoug we have tried it with
A & B).
The problem we are observing is that we can get the machines to connect
and communicate with each other but when we try to move files from
machine to the other we get the message “host is down” and “Bad File
Descriptor”
This situation gets more confusing in that if we ‘pull’ the files from
the remote machine then QNET will not fail if we ‘push’ the files then
it dies and the only way to recover is to remount QNET!
Does anyone have any suggestions/ideas?
I take it you are using tcpip binding. How about try QNET with
tiny tcpip stack? I think we’ve addressed several issue in bsd stack,
and I am not sure when this thing get out.
P.S. upgrading to QNX6.1 IS NOT an option as it does not appear to
support IP (with QNET) and we are still worried about its stability.
QNET on 6.1 DO support IP, it’s just it is not default anymore.
You need to mount qnet as:
mount -Tio-net -o bind=ip,resolve=dns /lib/dll/npm-qnet.so
-xtang
