We are using the Net.ether82557 Ethernet driver. We were running at 10
Mbit, though a 10 Mbit Hub, with only 3 QNX nodes on the Hub, note this
network card does not have TCP/IP enabled on it. Due to unusual slow
processes on our system we chose to upgrade the network to 100 Mbit. After
upgrading we then attempted to copy our databases to a backup server for
shadowing purposes and when we got to the larger files, in the 200 Meg range
we lost the route to the destination and the copy appeared to reverse it’s
self:
Original Command: cp -v //1/directory/filename //2/directory/filename
After we lost the route the verbose message displayed:
cp //2/directory/filename
//1/directory/filename
This appears to have corrupted the files.
I added the -n option to the Net.ether82557 command line with a retry of 10,
this seems to have prevented the problem of the copy not working and losing
the route to the host.
My question is why did this happen in the first place? Is it a problem with
the switch we used, Allied Telesyn 5 Port Switch? At the time the 3rd node
wasn’t even powered on so there were only the 2 nodes active. The copy of
the big files also seems to be slower no that we have the retry 10 in the
command line, over the time to copy at 10 Mbit.
Suggestions/Answers are welcome.
Thanks,
Matt
Previously, Matthew S. Blackburn wrote in qdn.public.qnx4:
We are using the Net.ether82557 Ethernet driver. We were running at 10
Mbit, though a 10 Mbit Hub, with only 3 QNX nodes on the Hub, note this
network card does not have TCP/IP enabled on it. Due to unusual slow
processes on our system we chose to upgrade the network to 100 Mbit. After
upgrading we then attempted to copy our databases to a backup server for
shadowing purposes and when we got to the larger files, in the 200 Meg range
we lost the route to the destination and the copy appeared to reverse it’s
self:
Original Command: cp -v //1/directory/filename //2/directory/filename
After we lost the route the verbose message displayed:
cp //2/directory/filename
//1/directory/filename
This appears to have corrupted the files.
I added the -n option to the Net.ether82557 command line with a retry of 10,
this seems to have prevented the problem of the copy not working and losing
the route to the host.
My question is why did this happen in the first place? Is it a problem with
the switch we used, Allied Telesyn 5 Port Switch? At the time the 3rd node
wasn’t even powered on so there were only the 2 nodes active. The copy of
the big files also seems to be slower no that we have the retry 10 in the
command line, over the time to copy at 10 Mbit.
Suggestions/Answers are welcome.
Is your switch setup for full or half-duplex? If it is set at full-duplex,
does setting it to half-duplex solve the problem?
Thanks,
Matt
\
–
Hugh Brown (613) 591-0931 ext. 209 (voice)
QNX Software Systems Ltd. (613) 591-3579 (fax)
175 Terence Matthews Cres. email: hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
There isn’t a way to set the switch to Half Duplex as it is Full Auto
Sensing. But, I didn’t set the “-F” switch on the Ethernet driver. Would
this possibly help or is it a red herring.
_M
“Hugh Brown” <hsbrown@qnx.com> wrote in message
news:Voyager.001218051921.13810B@qnx.com…
Previously, Matthew S. Blackburn wrote in qdn.public.qnx4:
We are using the Net.ether82557 Ethernet driver. We were running at 10
Mbit, though a 10 Mbit Hub, with only 3 QNX nodes on the Hub, note this
network card does not have TCP/IP enabled on it. Due to unusual slow
processes on our system we chose to upgrade the network to 100 Mbit.
After
upgrading we then attempted to copy our databases to a backup server for
shadowing purposes and when we got to the larger files, in the 200 Meg
range
we lost the route to the destination and the copy appeared to reverse
it’s
self:
Original Command: cp -v //1/directory/filename //2/directory/filename
After we lost the route the verbose message displayed:
cp //2/directory/filename
//1/directory/filename
This appears to have corrupted the files.
I added the -n option to the Net.ether82557 command line with a retry of
10,
this seems to have prevented the problem of the copy not working and
losing
the route to the host.
My question is why did this happen in the first place? Is it a problem
with
the switch we used, Allied Telesyn 5 Port Switch? At the time the 3rd
node
wasn’t even powered on so there were only the 2 nodes active. The copy
of
the big files also seems to be slower no that we have the retry 10 in
the
command line, over the time to copy at 10 Mbit.
Suggestions/Answers are welcome.
Is your switch setup for full or half-duplex? If it is set at full-duplex,
does setting it to half-duplex solve the problem?
Thanks,
Matt
\
Hugh Brown (613) 591-0931 ext. 209 (voice)
QNX Software Systems Ltd. (613) 591-3579 (fax)
175 Terence Matthews Cres. email: > hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
Previously, Matthew S. Blackburn wrote in qdn.public.qnx4:
There isn’t a way to set the switch to Half Duplex as it is Full Auto
Sensing. But, I didn’t set the “-F” switch on the Ethernet driver. Would
this possibly help or is it a red herring.
_M
Most switches have a setup, so that you can change the configuration of the
ports. Please start the Net.ether82557 with ‘-vvv’ switches and post the
output. Please note that this output gets displayed directly to the console,
so start the driver in text mode.
Hugh.
“Hugh Brown” <> hsbrown@qnx.com> > wrote in message
news:> Voyager.001218051921.13810B@qnx.com> …
Previously, Matthew S. Blackburn wrote in qdn.public.qnx4:
We are using the Net.ether82557 Ethernet driver. We were running at 10
Mbit, though a 10 Mbit Hub, with only 3 QNX nodes on the Hub, note this
network card does not have TCP/IP enabled on it. Due to unusual slow
processes on our system we chose to upgrade the network to 100 Mbit.
After
upgrading we then attempted to copy our databases to a backup server for
shadowing purposes and when we got to the larger files, in the 200 Meg
range
we lost the route to the destination and the copy appeared to reverse
it’s
self:
Original Command: cp -v //1/directory/filename //2/directory/filename
After we lost the route the verbose message displayed:
cp //2/directory/filename
//1/directory/filename
This appears to have corrupted the files.
I added the -n option to the Net.ether82557 command line with a retry of
10,
this seems to have prevented the problem of the copy not working and
losing
the route to the host.
My question is why did this happen in the first place? Is it a problem
with
the switch we used, Allied Telesyn 5 Port Switch? At the time the 3rd
node
wasn’t even powered on so there were only the 2 nodes active. The copy
of
the big files also seems to be slower no that we have the retry 10 in
the
command line, over the time to copy at 10 Mbit.
Suggestions/Answers are welcome.
Is your switch setup for full or half-duplex? If it is set at full-duplex,
does setting it to half-duplex solve the problem?
Thanks,
Matt
\
–
Hugh Brown (613) 591-0931 ext. 209 (voice)
QNX Software Systems Ltd. (613) 591-3579 (fax)
175 Terence Matthews Cres. email: hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
The switches in question do not have a setup, they are unmanaged. For
specific information see the Allied Telesyn web site, and reference the
AT-FS705.
I will work on a time to bring my customer down and gather the output you
wish.
“Hugh Brown” <hsbrown@qnx.com> wrote in message
news:Voyager.001218104709.6787C@qnx.com…
Previously, Matthew S. Blackburn wrote in qdn.public.qnx4:
There isn’t a way to set the switch to Half Duplex as it is Full Auto
Sensing. But, I didn’t set the “-F” switch on the Ethernet driver.
Would
this possibly help or is it a red herring.
_M
Most switches have a setup, so that you can change the configuration of
the
ports. Please start the Net.ether82557 with ‘-vvv’ switches and post the
output. Please note that this output gets displayed directly to the
console,
so start the driver in text mode.
Hugh.
“Hugh Brown” <> hsbrown@qnx.com> > wrote in message
news:> Voyager.001218051921.13810B@qnx.com> …
Previously, Matthew S. Blackburn wrote in qdn.public.qnx4:
We are using the Net.ether82557 Ethernet driver. We were running at
10
Mbit, though a 10 Mbit Hub, with only 3 QNX nodes on the Hub, note
this
network card does not have TCP/IP enabled on it. Due to unusual
slow
processes on our system we chose to upgrade the network to 100 Mbit.
After
upgrading we then attempted to copy our databases to a backup server
for
shadowing purposes and when we got to the larger files, in the 200
Meg
range
we lost the route to the destination and the copy appeared to
reverse
it’s
self:
Original Command: cp -v //1/directory/filename
//2/directory/filename
After we lost the route the verbose message displayed:
cp //2/directory/filename
//1/directory/filename
This appears to have corrupted the files.
I added the -n option to the Net.ether82557 command line with a
retry of
10,
this seems to have prevented the problem of the copy not working and
losing
the route to the host.
My question is why did this happen in the first place? Is it a
problem
with
the switch we used, Allied Telesyn 5 Port Switch? At the time the
3rd
node
wasn’t even powered on so there were only the 2 nodes active. The
copy
of
the big files also seems to be slower no that we have the retry 10
in
the
command line, over the time to copy at 10 Mbit.
Suggestions/Answers are welcome.
Is your switch setup for full or half-duplex? If it is set at
full-duplex,
does setting it to half-duplex solve the problem?
Thanks,
Matt
\
Hugh Brown (613) 591-0931 ext. 209 (voice)
QNX Software Systems Ltd. (613) 591-3579 (fax)
175 Terence Matthews Cres. email: > hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8