Hi
I have problems with Net.ether82557-driver (or card) …
It seems that sometimes there are exists almost
20 seconds delays in network !!
(I have measured that by ping-command)
It also seems that 82557-card is not compatible
with our HUB… If i have direct connection without
any HUB (or other HUB), it seems to work without
delays …
I have tried different kind of options of Net.ether82557 …
(for example -s10 -F)
Where can i find new version of Net.ether82557 ?
Esa
Esa Heikkinen wrote:
Hi
I have problems with Net.ether82557-driver (or card) …
It seems that sometimes there are exists almost
20 seconds delays in network !!
(I have measured that by ping-command)It also seems that 82557-card is not compatible
with our HUB… If i have direct connection without
any HUB (or other HUB), it seems to work without
delays …
Hmmm, let’s re-examine the logic here.
a) You have a Intel 82557 card, and a QNX driver for that card.
b) You have a switch (or hub).
Based on this evidence, I see the logical conclusion being that there is
a problem with the hub. How is it that you come to the conclusion that
the QNX driver is the problem ?
I would suggest that you:
a) Disconnect everything from the hub, other than the same two machines
that you used for the back-to-back test.
b) Test latency with the FLEET (rather than TCP/IP - which is
non-deterministic).
c) Investigate whether you have a hub or a switch, and whether it
supports full-duplex or not.
Rennie
Hello Rennie,
Some experience shows that FLEET is as not quick as is expected to be. In
case that FLEET is built on two networks for redundence, switiching from one
network to another for FLEET sometime take 20ms. I think this is not
reasonable. Do you think some thing is wrong with my setup?
Thanks.
“Rennie Allen” <rallen@csical.com> wrote in message
news:3CB31279.1000802@csical.com…
Esa Heikkinen wrote:
Hi
I have problems with Net.ether82557-driver (or card) …
It seems that sometimes there are exists almost
20 seconds delays in network !!
(I have measured that by ping-command)It also seems that 82557-card is not compatible
with our HUB… If i have direct connection without
any HUB (or other HUB), it seems to work without
delays …Hmmm, let’s re-examine the logic here.
a) You have a Intel 82557 card, and a QNX driver for that card.
b) You have a switch (or hub).
- When you connect the 82557 to another 82557 using the QNX driver
everything works as you expect.- When you connect the 82557 to the hub, you experience problems.
Based on this evidence, I see the logical conclusion being that there is
a problem with the hub. How is it that you come to the conclusion that
the QNX driver is the problem ?I would suggest that you:
a) Disconnect everything from the hub, other than the same two machines
that you used for the back-to-back test.
b) Test latency with the FLEET (rather than TCP/IP - which is
non-deterministic).
c) Investigate whether you have a hub or a switch, and whether it
supports full-duplex or not.Rennie
Newsgroup wrote:
Hello Rennie,
Some experience shows that FLEET is as not quick as is expected to be. In
case that FLEET is built on two networks for redundence, switiching from one
network to another for FLEET sometime take 20ms. I think this is not
reasonable. Do you think some thing is wrong with my setup?
Thanks.
We are dicussing two distinctly different subjects here. One being
transport latency (the time it takes a packet to go from one node to
another) and failover latency (the time it takes for QNX to recognize a
link failure).
I am somewhat confused with exactly what it is you are referring to when
referring to failover latency, since the way redundant LAN’s work in
QNX4, is that both links are used simultaneously, hence there is no
failover latency per se (although there will be a disturbance to
transport throughput commensurate with the data that was lost on the
link that failed, and recovered with the now diminished capacity (since
there are fewer links available following the failure).
It is impossible to comment further, without much greater detail about
what it is you are doing.
Rennie
When using FLEET on redundant LAN I set the Net. to use “-n1 -t3”.
This will very occasionally give the results of an assumed network error
when no such error exists (it was just a little slow). But it is able to
take advantage of the second network much much quicker.
If it does result in too many artificial network errors just raise the -n
and -t number slightly until they go away.
“Newsgroup” <news@leadingtek.com.cn> wrote in message
news:a8v8ce$t0u$1@inn.qnx.com…
Hello Rennie,
Some experience shows that FLEET is as not quick as is expected to be. In
case that FLEET is built on two networks for redundence, switiching from
one
network to another for FLEET sometime take 20ms. I think this is not
reasonable. Do you think some thing is wrong with my setup?
Thanks.“Rennie Allen” <> rallen@csical.com> > wrote in message
news:> 3CB31279.1000802@csical.com> …
Esa Heikkinen wrote:Hi
I have problems with Net.ether82557-driver (or card) …
It seems that sometimes there are exists almost
20 seconds delays in network !!
(I have measured that by ping-command)It also seems that 82557-card is not compatible
with our HUB… If i have direct connection without
any HUB (or other HUB), it seems to work without
delays …Hmmm, let’s re-examine the logic here.
a) You have a Intel 82557 card, and a QNX driver for that card.
b) You have a switch (or hub).
- When you connect the 82557 to another 82557 using the QNX driver
everything works as you expect.- When you connect the 82557 to the hub, you experience problems.
Based on this evidence, I see the logical conclusion being that there is
a problem with the hub. How is it that you come to the conclusion that
the QNX driver is the problem ?I would suggest that you:
a) Disconnect everything from the hub, other than the same two machines
that you used for the back-to-back test.
b) Test latency with the FLEET (rather than TCP/IP - which is
non-deterministic).
c) Investigate whether you have a hub or a switch, and whether it
supports full-duplex or not.Rennie
I understand what he is talking about.
We use redundant networks on audio workstations. You can be playing audio
through the network, unplug one network and the audio keeps on playing.
Unplug the other network and the audio keeps on playing.
To other person:
QNX4 will favor the first network where a path exists to the destination
node for ALL traffic unless there is a detected failure on the first
network. Then and only then it will try the second network. IT DOES NOT
LOAD BALANCE!
The exception to this rule is if the network has an advertised media rate
(-r) 10 times faster then the first network. In which case it will use that
network for all traffic.
However, we found a way to do some manual loadbalancing with redundant
networks. In out environment we have a file server and many workstations.
Most traffic is to or from the server. Therefore we lie to the network
drivers about the advertised media rate. This forces all of the outbound
traffic from the servers on to LAN #1 (never a collision) and forces all
inbound traffic to the servers on to LAN #2 (rarely a collision).
“Rennie Allen” <rallen@csical.com> wrote in message
news:3CB32AC7.7030705@csical.com…
Newsgroup wrote:
Hello Rennie,
Some experience shows that FLEET is as not quick as is expected to be.
In
case that FLEET is built on two networks for redundence, switiching from
one
network to another for FLEET sometime take 20ms. I think this is not
reasonable. Do you think some thing is wrong with my setup?
Thanks.
We are dicussing two distinctly different subjects here. One being
transport latency (the time it takes a packet to go from one node to
another) and failover latency (the time it takes for QNX to recognize a
link failure).
I am somewhat confused with exactly what it is you are referring to when
referring to failover latency, since the way redundant LAN’s work in
QNX4, is that both links are used simultaneously, hence there is no
failover latency per se (although there will be a disturbance to
transport throughput commensurate with the data that was lost on the
link that failed, and recovered with the now diminished capacity (since
there are fewer links available following the failure).It is impossible to comment further, without much greater detail about
what it is you are doing.Rennie
Bill Caroselli (Q-TPS) wrote:
I understand what he is talking about.
We use redundant networks on audio workstations. You can be playing audio
through the network, unplug one network and the audio keeps on playing.
Unplug the other network and the audio keeps on playing.To other person:
QNX4 will favor the first network where a path exists to the destination
node for ALL traffic unless there is a detected failure on the first
network. Then and only then it will try the second network. IT DOES NOT
LOAD BALANCE!
FLEET DOES LOAD BALANCE (hey my caps lock key does work 
Why it wasn’t load-balancing for you, I don’t know, but we are using it
here for synchronizing redundant controllers. The load balancing can be
seen very clearly on our system, as the speed at which our controllers
scan I/O is a function of the size of the pipe they have to synchronize
through. If you set up a test where the controllers are updating
outputs rapidly, and then pull one of the redundant ethernet cables that
link the controllers, you can see the update rate of the controllers
drop, as the synchronization takes longer (due to only a single lan),
plug the cable back in and the update rate returns to normal. Of
course, in any of the applications that use the controllers we consider
the single lan update rate as the worst case scan time, the improved
speed in normal operation is simply a bonus.
In order to make use of the load balancing you must transfer data
asynchronously across the lan (since sending it synchronously leaves
your application blocked until it receives the reply - at which point
the the lan that you last sent on is obviously ready to accept data
again - in this way it might appear that one card is being favored).
Was your application using synchronous message passing ?
btw: FLEET stands for Fault-tolerant Load-balancing Extensible Efficient
Transport.
Rennie
We use many apps talking across the lans (as opposed to your asynchronous
method. Can native QNX networking ever send a message asynchronously?
And Yes, I know what fleet stands for. I have just never experienced it.
“Rennie Allen” <rallen@csical.com> wrote in message
news:3CB350DF.5040904@csical.com…
Bill Caroselli (Q-TPS) wrote:
I understand what he is talking about.
We use redundant networks on audio workstations. You can be playing
audio
through the network, unplug one network and the audio keeps on playing.
Unplug the other network and the audio keeps on playing.To other person:
QNX4 will favor the first network where a path exists to the destination
node for ALL traffic unless there is a detected failure on the first
network. Then and only then it will try the second network. IT DOES
NOT
LOAD BALANCE!FLEET DOES LOAD BALANCE (hey my caps lock key does work >
Why it wasn’t load-balancing for you, I don’t know, but we are using it
here for synchronizing redundant controllers. The load balancing can be
seen very clearly on our system, as the speed at which our controllers
scan I/O is a function of the size of the pipe they have to synchronize
through. If you set up a test where the controllers are updating
outputs rapidly, and then pull one of the redundant ethernet cables that
link the controllers, you can see the update rate of the controllers
drop, as the synchronization takes longer (due to only a single lan),
plug the cable back in and the update rate returns to normal. Of
course, in any of the applications that use the controllers we consider
the single lan update rate as the worst case scan time, the improved
speed in normal operation is simply a bonus.In order to make use of the load balancing you must transfer data
asynchronously across the lan (since sending it synchronously leaves
your application blocked until it receives the reply - at which point
the the lan that you last sent on is obviously ready to accept data
again - in this way it might appear that one card is being favored).
Was your application using synchronous message passing ?btw: FLEET stands for Fault-tolerant Load-balancing Extensible Efficient
Transport.Rennie
Bill Caroselli (Q-TPS) wrote:
We use many apps talking across the lans (as opposed to your asynchronous
method. Can native QNX networking ever send a message asynchronously?
Sure. It’s called reply driven messaging.
And Yes, I know what fleet stands for. I have just never experienced it.
It does work, but as I said, it is impossible to see a benefit with
synchronous messaging.
Rennie
“Rennie Allen” <rallen@csical.com> wrote in message
news:3CB31279.1000802@csical.com…
Esa Heikkinen wrote:
Hi
I have problems with Net.ether82557-driver (or card) …
It seems that sometimes there are exists almost
20 seconds delays in network !!
(I have measured that by ping-command)It also seems that 82557-card is not compatible
with our HUB… If i have direct connection without
any HUB (or other HUB), it seems to work without
delays …Hmmm, let’s re-examine the logic here.
a) You have a Intel 82557 card, and a QNX driver for that card.
b) You have a switch (or hub).
- When you connect the 82557 to another 82557 using the QNX driver
everything works as you expect.- When you connect the 82557 to the hub, you experience problems.
Based on this evidence, I see the logical conclusion being that there is
a problem with the hub. How is it that you come to the conclusion that
the QNX driver is the problem ?
I dont know where is the problem …
I have another computer also behind the HUB.
This computer is laptop with D-link De-660 -networkcard and
i am using Net.ether1000-driver (and QNX) in this computer.
Network in this computer works fine without latencies…
Third “test”-computer sends ping-messages to laptop and
“82557”-computer.
Esa
Hello Rennie,
Sorry for my intrusion. I am looking through the bulletins(?) here and find
that yours is very helpful, this remind me one of my perpelex before. I thus
take liberty to raise a new question. I can conclude that your QNX
application is very helpful and tried to visit you webpage in vain (it says
"Hier entsteht eine neue Internetpr?senz ! "–Here is a new Internet
Apperance Fault?). Hope that we might have chance to co-operate.
Hello Bill,
Thanks for your suggestion. I will try again with your help.
Thanks.
Shrimp
2002-04-10
“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:a8vagl$1ak$1@inn.qnx.com…
I understand what he is talking about.
We use redundant networks on audio workstations. You can be playing audio
through the network, unplug one network and the audio keeps on playing.
Unplug the other network and the audio keeps on playing.To other person:
QNX4 will favor the first network where a path exists to the destination
node for ALL traffic unless there is a detected failure on the first
network. Then and only then it will try the second network. IT DOES NOT
LOAD BALANCE!The exception to this rule is if the network has an advertised media rate
(-r) 10 times faster then the first network. In which case it will use
that
network for all traffic.However, we found a way to do some manual loadbalancing with redundant
networks. In out environment we have a file server and many workstations.
Most traffic is to or from the server. Therefore we lie to the network
drivers about the advertised media rate. This forces all of the outbound
traffic from the servers on to LAN #1 (never a collision) and forces all
inbound traffic to the servers on to LAN #2 (rarely a collision).
“Rennie Allen” <> rallen@csical.com> > wrote in message
news:> 3CB32AC7.7030705@csical.com> …
Newsgroup wrote:Hello Rennie,
Some experience shows that FLEET is as not quick as is expected to be.
In
case that FLEET is built on two networks for redundence, switiching
from
one
network to another for FLEET sometime take 20ms. I think this is not
reasonable. Do you think some thing is wrong with my setup?
Thanks.
We are dicussing two distinctly different subjects here. One being
transport latency (the time it takes a packet to go from one node to
another) and failover latency (the time it takes for QNX to recognize a
link failure).
I am somewhat confused with exactly what it is you are referring to when
referring to failover latency, since the way redundant LAN’s work in
QNX4, is that both links are used simultaneously, hence there is no
failover latency per se (although there will be a disturbance to
transport throughput commensurate with the data that was lost on the
link that failed, and recovered with the now diminished capacity (since
there are fewer links available following the failure).It is impossible to comment further, without much greater detail about
what it is you are doing.Rennie
Esa Heikkinen wrote:
I dont know where is the problem …
I have another computer also behind the HUB.
This computer is laptop with D-link De-660 -networkcard and
i am using Net.ether1000-driver (and QNX) in this computer.
Network in this computer works fine without latencies…
Well, one difference here is that the Net.ether1000 driver is 10Mbit
half-duplex only. Perhaps the hub has a problem with full-duplex or
perhaps it is managing traffic between 10 and 100 Mbit and the delay is
caused by buffering latencies ?
Rennie
I experienced a problem similar to this with an older version of the
Net.ether82557 driver. What version are you using?
Esa Heikkinen <esa.heikkinen@insta.fi> wrote in message
news:a8uqd4$j3g$1@inn.qnx.com…
Hi
I have problems with Net.ether82557-driver (or card) …
It seems that sometimes there are exists almost
20 seconds delays in network !!
(I have measured that by ping-command)It also seems that 82557-card is not compatible
with our HUB… If i have direct connection without
any HUB (or other HUB), it seems to work without
delays …I have tried different kind of options of Net.ether82557 …
(for example -s10 -F)Where can i find new version of Net.ether82557 ?
Esa
\
“Rennie Allen” <rallen@csical.com> wrote in message
news:3CB45945.3020403@csical.com…
Esa Heikkinen wrote:
I dont know where is the problem …I have another computer also behind the HUB.
This computer is laptop with D-link De-660 -networkcard and
i am using Net.ether1000-driver (and QNX) in this computer.
Network in this computer works fine without latencies…
Well, one difference here is that the Net.ether1000 driver is 10Mbit
half-duplex only. Perhaps the hub has a problem with full-duplex or
perhaps it is managing traffic between 10 and 100 Mbit and the delay is
caused by buffering latencies ?
Command: “Net.ether82557 -s10” should be correct for that ?
(This mean 10Mbit and half-duplex, because it is default).
I have tried that, but not seems to work …
Esa
“Stephen Thomas” <slthomas@corpDOTolin.com> wrote in message
news:a92dfr$b53$1@inn.qnx.com…
I experienced a problem similar to this with an older version of the
Net.ether82557 driver. What version are you using?
I dont find version number, but timestamp is
4.12.1998
Where would i find new version (URL) ?
Esa
Esa Heikkinen <> esa.heikkinen@insta.fi> > wrote in message
news:a8uqd4$j3g$> 1@inn.qnx.com> …Hi
I have problems with Net.ether82557-driver (or card) …
It seems that sometimes there are exists almost
20 seconds delays in network !!
(I have measured that by ping-command)It also seems that 82557-card is not compatible
with our HUB… If i have direct connection without
any HUB (or other HUB), it seems to work without
delays …I have tried different kind of options of Net.ether82557 …
(for example -s10 -F)Where can i find new version of Net.ether82557 ?
Esa
\
To get the version number of running software type:
sin ve
Your version of Net.ether.82557 is old. Mine is Jan 11, 2001. I know there
was some major bug fixes. I don’t remember exactly when they went in.
Someone from QSSL will have to give a URL. I still go back to the QUICS
system for QNX4 updates. But I don’t think you can log onto it unless you
had a QUICS ID from way back when.
“Esa Heikkinen” <esa.heikkinen@insta.fi> wrote in message
news:a93hh0$61o$1@inn.qnx.com…
“Stephen Thomas” <> slthomas@corpDOTolin.com> > wrote in message
news:a92dfr$b53$> 1@inn.qnx.com> …I experienced a problem similar to this with an older version of the
Net.ether82557 driver. What version are you using?
I dont find version number, but timestamp is
4.12.1998Where would i find new version (URL) ?
Esa
Esa Heikkinen <> esa.heikkinen@insta.fi> > wrote in message
news:a8uqd4$j3g$> 1@inn.qnx.com> …Hi
I have problems with Net.ether82557-driver (or card) …
It seems that sometimes there are exists almost
20 seconds delays in network !!
(I have measured that by ping-command)It also seems that 82557-card is not compatible
with our HUB… If i have direct connection without
any HUB (or other HUB), it seems to work without
delays …I have tried different kind of options of Net.ether82557 …
(for example -s10 -F)Where can i find new version of Net.ether82557 ?
Esa
\
This version is definitely BROKEN. You can get an update on qdn.qnx.com
(somewhere)
“Esa Heikkinen” <esa.heikkinen@insta.fi> wrote in message
news:a93hh0$61o$1@inn.qnx.com…
“Stephen Thomas” <> slthomas@corpDOTolin.com> > wrote in message
news:a92dfr$b53$> 1@inn.qnx.com> …I experienced a problem similar to this with an older version of the
Net.ether82557 driver. What version are you using?
I dont find version number, but timestamp is
4.12.1998Where would i find new version (URL) ?
Esa
Esa Heikkinen <> esa.heikkinen@insta.fi> > wrote in message
news:a8uqd4$j3g$> 1@inn.qnx.com> …Hi
I have problems with Net.ether82557-driver (or card) …
It seems that sometimes there are exists almost
20 seconds delays in network !!
(I have measured that by ping-command)It also seems that 82557-card is not compatible
with our HUB… If i have direct connection without
any HUB (or other HUB), it seems to work without
delays …I have tried different kind of options of Net.ether82557 …
(for example -s10 -F)Where can i find new version of Net.ether82557 ?
Esa
\
“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:a949om$mu1$1@inn.qnx.com…
To get the version number of running software type:
sin veYour version of Net.ether.82557 is old. Mine is Jan 11, 2001. I know
there
was some major bug fixes. I don’t remember exactly when they went in.Someone from QSSL will have to give a URL. I still go back to the QUICS
system for QNX4 updates. But I don’t think you can log onto it unless you
had a QUICS ID from way back when.
I have to say it is a quite difficult to find that driver from QNX-sites
…
(Even i should have this QUICS ID). That seems to be more
difficult than few years ago, when i have got files …
Does that belong to other packet of is it “single” file ?
By the way … how can i extract *.tarx-files ???
(Those files are in tcpip_rt2.tar-file…)
Most new tcprt-packet is 4.25c.tcprt.tar.F or tcpip_rt2.tar ?
Esa
On QUICS go get /updates/qnx42/Released/qnx425E.tar.F
Then you can pull out Net.ether82557 with:
melt < qnx425E.tar.F | pax -vr /bin/Net.ether82557
“Esa Heikkinen” <esa.heikkinen@insta.fi> wrote in message
news:a96jom$e9a$1@inn.qnx.com…
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:a949om$mu1$> 1@inn.qnx.com> …
To get the version number of running software type:
sin veYour version of Net.ether.82557 is old. Mine is Jan 11, 2001. I know
there
was some major bug fixes. I don’t remember exactly when they went in.Someone from QSSL will have to give a URL. I still go back to the QUICS
system for QNX4 updates. But I don’t think you can log onto it unless
you
had a QUICS ID from way back when.
I have to say it is a quite difficult to find that driver from
QNX-sites
…
(Even i should have this QUICS ID). That seems to be more
difficult than few years ago, when i have got files …Does that belong to other packet of is it “single” file ?
By the way … how can i extract *.tarx-files ???
(Those files are in tcpip_rt2.tar-file…)Most new tcprt-packet is 4.25c.tcprt.tar.F or tcpip_rt2.tar ?
If i try to find Net.ether82557 in QNX-sites, i find only documents
and
not this driver what i am looking for …
\Esa
\
Now the network works very well without latencies )
Thanks for all !!
Esa
“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:a9735p$os2$1@inn.qnx.com…
On QUICS go get /updates/qnx42/Released/qnx425E.tar.F
Then you can pull out Net.ether82557 with:
melt < qnx425E.tar.F | pax -vr /bin/Net.ether82557“Esa Heikkinen” <> esa.heikkinen@insta.fi> > wrote in message
news:a96jom$e9a$> 1@inn.qnx.com> …“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:a949om$mu1$> 1@inn.qnx.com> …
To get the version number of running software type:
sin veYour version of Net.ether.82557 is old. Mine is Jan 11, 2001. I know
there
was some major bug fixes. I don’t remember exactly when they went in.Someone from QSSL will have to give a URL. I still go back to the
QUICS
system for QNX4 updates. But I don’t think you can log onto it unless
you
had a QUICS ID from way back when.
I have to say it is a quite difficult to find that driver from
QNX-sites
…
(Even i should have this QUICS ID). That seems to be more
difficult than few years ago, when i have got files …Does that belong to other packet of is it “single” file ?
By the way … how can i extract *.tarx-files ???
(Those files are in tcpip_rt2.tar-file…)Most new tcprt-packet is 4.25c.tcprt.tar.F or tcpip_rt2.tar ?
If i try to find Net.ether82557 in QNX-sites, i find only documents
and
not this driver what i am looking for …
\Esa
\