Project Home
Project Home
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - QNet with "hot swappable" devices, boot times: (8 Items)
   
QNet with "hot swappable" devices, boot times  
Hi,

we are designing a system where we have several integrated CPUs and also external modules that are connected and 
disconnected while the main system is running.

I am concerned about the following:

1. how fast will the QNX nodes find each other upon system boot? Is there anything we can do to aid node discovery to be
 faster/more efficient? Anything one should avoid?

2. when the external modules are un-docked, the old node will be lingering for some time in /net. We do have knowledge 
whether the external module is connected or not (be means of physical contacts), can we use this to somehow make qnx "
purge" the old /net entry right away? Our worst case scenario would be undocking an external module, plugging in another
 (but physically identical) module, and the old connection would linger and the new one couldn't be used...

3. currently, we have only one external module docked/plugged in. My plan was to give each module a unique hostname, so 
those appear nicely with an intelligible name under /net. Now the potential problem is:
a) what happens when in later versions there are two identical external modules plugged in
b) what happens to the names upon undocking a module and swapping it for another one? Will anybody notice? Can anybody 
notice? How to tell the main system software that now another module has been docked in?

Thanks & Greetings,
 Marc
Re: QNet with "hot swappable" devices, boot times  
just to add some clarification.. our ideal system would look something like this:
/net/mainsys_cpu1
/net/mainsys_cpu2
/net/dock1
/net/dock2
where dock1 and dock2 are hot swappable external modules. The modules do know in what slot they are, so they can be 
assigned unique hostnames upon boot.
RE: QNet with "hot swappable" devices, boot times  
If you have other means to know a node goes away, and a node comes in,
you can do this more reliable.

1) When a node goes away, you can tell QNET by doing a:

	rmdir("/net/dock1");

   This will force QNET to do a "node down" on /net/dock1, and clean up
accordingly. 

2) When a node coming in, you can force QNET to "discover" it, by:

      while((fd = open("/net/dock1/dev/null", O_RDONLY)) == -1) {
		sleep(1);
	}

Regards,

-xtang

> -----Original Message-----
> From: Marc Roessler [mailto:community-noreply@qnx.com]
> Sent: January 22, 2009 7:47 AM
> To: technology-networking
> Subject: QNet with "hot swappable" devices, boot times
> 
> Hi,
> 
> we are designing a system where we have several integrated CPUs and
also
> external modules that are connected and disconnected while the main
system
> is running.
> 
> I am concerned about the following:
> 
> 1. how fast will the QNX nodes find each other upon system boot? Is
there
> anything we can do to aid node discovery to be faster/more efficient?
> Anything one should avoid?
> 
> 2. when the external modules are un-docked, the old node will be
lingering
> for some time in /net. We do have knowledge whether the external
module is
> connected or not (be means of physical contacts), can we use this to
> somehow make qnx "purge" the old /net entry right away? Our worst case
> scenario would be undocking an external module, plugging in another
(but
> physically identical) module, and the old connection would linger and
the
> new one couldn't be used...
> 
> 3. currently, we have only one external module docked/plugged in. My
plan
> was to give each module a unique hostname, so those appear nicely with
an
> intelligible name under /net. Now the potential problem is:
> a) what happens when in later versions there are two identical
external
> modules plugged in
> b) what happens to the names upon undocking a module and swapping it
for
> another one? Will anybody notice? Can anybody notice? How to tell the
main
> system software that now another module has been docked in?
> 
> Thanks & Greetings,
>  Marc
> 
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post20568
Re: RE: QNet with "hot swappable" devices, boot times  
That's cool, thanks!
As usual, it's much easier than expected...

RE: RE: QNet with "hot swappable" devices, boot times  
> it's much easier than expected...

The file system model for node management is
pretty handy.  For example, if you want to
shut down all qnet connections, free up all
blocked clients (on remote servers) you can:

  # rmdir /net/*

which will whine about your own hostname, 
but just ignore it, because it won't go
away.  If you immediately

  # ls /net

afterwards, you will see your own hostname.

I should mention that if you see a nodename
in /net it doesn't mean that node is necessarily
up - just that qnet has a mapping, from that
hostname to a mac address.

In the absence of any user activity (as xtang
explained), every 30 seconds (by default - you
can change it to whatever you want) each qnet
node will transmit a "gratuitous arp" describing
itself, which over time will populate /net
which is nice.

But a node could be powered up for a minute,
then power down again.  Or, it could change
it's hostname.  You can "clean out" /net
by doing this:

  # ls -l /net

which will cause qnet to try to establish
a connection to each entry in /net, in order
that application data can flow.  Any unresponding
nodes will be cleaned out of /net in the process.

To learn more about the current status of
the qnet connections to various remote nodes,
run:

  # cat /proc/qnetstats | less

--
aboyd
RE: RE: QNet with "hot swappable" devices, boot times  
Why the design choice to not timeout entries in /net to make them go away?

> -----Original Message-----
> From: Andrew Boyd [mailto:community-noreply@qnx.com]
> Sent: January-22-09 10:10 AM
> To: technology-networking
> Subject: RE: RE: QNet with "hot swappable" devices, boot times
> 
> 
> > it's much easier than expected...
> 
> The file system model for node management is
> pretty handy.  For example, if you want to
> shut down all qnet connections, free up all
> blocked clients (on remote servers) you can:
> 
>   # rmdir /net/*
> 
> which will whine about your own hostname,
> but just ignore it, because it won't go
> away.  If you immediately
> 
>   # ls /net
> 
> afterwards, you will see your own hostname.
> 
> I should mention that if you see a nodename
> in /net it doesn't mean that node is necessarily
> up - just that qnet has a mapping, from that
> hostname to a mac address.
> 
> In the absence of any user activity (as xtang
> explained), every 30 seconds (by default - you
> can change it to whatever you want) each qnet
> node will transmit a "gratuitous arp" describing
> itself, which over time will populate /net
> which is nice.
> 
> But a node could be powered up for a minute,
> then power down again.  Or, it could change
> it's hostname.  You can "clean out" /net
> by doing this:
> 
>   # ls -l /net
> 
> which will cause qnet to try to establish
> a connection to each entry in /net, in order
> that application data can flow.  Any unresponding
> nodes will be cleaned out of /net in the process.
> 
> To learn more about the current status of
> the qnet connections to various remote nodes,
> run:
> 
>   # cat /proc/qnetstats | less
> 
> --
> aboyd
> 
> 
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post20600
> 
RE: RE: QNet with "hot swappable" devices, boot times  
> not timeout entries in /net to make them go away?

I suppose you could add that functionality to qnet,
but unless it's an essential feature, and it can 
only be accomplished inside of qnet, I would be
reluctant to add it.  You could implement this 
outside of qnet pretty easily (a cron task),
and keep the system as modular as possible.

I suspect a lot of people don't know about
/net and for their application, don't care.

--
aboyd

RE: RE: QNet with "hot swappable" devices, boot times  
If you attempt to access a node that has "gone away", then the entry
will actually be removed.  QNET itself doesn't actively poll remote
nodes to detect when they do disappear, but it is very easy to create a
heartbeat application that would do so.  Given that there would be a
variety of use cases (ranging from "we need to know within 10 msec" to
"we want to minimize all traffic between nodes"), this is something
which is best left to the end user, especially given how easy it is to
implement.

	R.


-----Original Message-----
From: Andrew Boyd [mailto:community-noreply@qnx.com] 
Sent: Thursday, January 22, 2009 10:48 AM
To: technology-networking
Subject: RE: RE: QNet with "hot swappable" devices, boot times


> not timeout entries in /net to make them go away?

I suppose you could add that functionality to qnet, but unless it's an
essential feature, and it can only be accomplished inside of qnet, I
would be reluctant to add it.  You could implement this outside of qnet
pretty easily (a cron task), and keep the system as modular as possible.

I suspect a lot of people don't know about /net and for their
application, don't care.

--
aboyd



_______________________________________________
Technology
http://community.qnx.com/sf/go/post20610