linux-um archives
 help / color / mirror / Atom feed
From: Jon Maloy <jon.maloy@ericsson.com>
To: Randy Macleod <macleodr@nortelnetworks.com>
Cc: user-mode-linux-devel@lists.sourceforge.net,
	tipc-discussion@lists.sourceforge.net
Subject: [uml-devel] Re: [tipc-discussion] tipc in networked UML
Date: Wed, 18 Aug 2004 15:24:26 -0400	[thread overview]
Message-ID: <4123ACEA.6080600@ericsson.com> (raw)
In-Reply-To: 4123A17A.9070200@americasm01.nt.com

See below
/jon

Randy Macleod wrote:

>
> Hello,
>
>    I'm simulating a small cluster of processors using
> UML (user-mode-linux.sourceforge.net)
> and TIPC (tipc.sf.net).
> Has anyone else tried this?
>
> The network is simulated using tun devices, i.e.
>
> cpu0 with eth0 in a UML is connected to pce.0.0.0
> cpu1 with eth0 in a UML is connected to pce.0.1.0
>
> A bridge device connects these pce(s) and forwards
> ethernet frames based on mac addrs. Packet delivery
> is communicated to the UML receiver by a signal according
> to Jeff Dike (the UML guy)
>
> Below is some output of /sbin/ifconfig -a on the desktop...
>
> Now when these UML's load, a tipc kernel module gets insmod'ed
> and things work to first order as expected.
> BUT...
> Several problems occur:
>
> 1. Connectionless communication is very unreliable.
>   (see my previous post for tfsend/tfrecv))
>   Only 100's of messages can be exchanged before getting
>   a sequence error. 

At least this should make it easier to reproduce and track down the
problem you identified in your previous mail...

>
>
> 2. Resetting 1 node causes confusion of the tipc name table
> of other nodes.
>
> If I have 3 UML's (A,B,C),
>  - publish a tipcname on A,
>  - reset node C
>  - then node A get stuck periodically withdrawing the published name. 

Do you mean node A hangs ? (Btw, are you running the latest version 
tipc-1.3.14 ?,
I fixed a quite nasty bug in one of the later versions, where equal 
publications
from different nodes got the same publication key, with the result that 
the wrong
publication was removed sometimes)

>
>
>
> 3. On a lightly loaded system with 10s of processes per UML,
>    there are frequently very long (> 5 seconds) tipc packet latencies
>    whereas the normal latency is 0.3 seconds. The desktop load
>    is always very low. If I ping each node every 0.1 seconds
>    the high latencies mostly go away. Seem's like the signal
>    is missed... 

>
>
> So, does TIPC assume real-time behaviour
> of packets on the network. i.e. by the time N packets have been
> sent, the other kernels have received the packets and will send
> flow control messages? 

To work really well we assume that there is real parallelism, but TIPC
should never fail because of long latency times.  
I think I have a seen similar effect on VmWare.

>
>
> If this is the case then I think a minimal modification to UML
> to do a sched_yield() every N packets (in or out) would
> help matters. Furthermore, it may be a good idea to co-operatively
> schedule all the UML's so that their clocks are all in sync and
> no node can send or receive too many packets at one time.
>
> Comments?
>
> // Randy
>
>
>
>
> cpbr.0    Link encap:Ethernet  HWaddr 00:FF:3A:1A:CB:69
>           inet addr:10.0.254.1  Bcast:10.255.255.255  Mask:255.255.0.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:52 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:1624 (1.5 Kb)  TX bytes:704 (704.0 b)
>
> pce.0.0.0 Link encap:Ethernet  HWaddr 00:FF:E2:5D:50:B0
>           UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
>           RX packets:3262 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:2562 errors:0 dropped:149 overruns:0 carrier:0
>           collisions:0 txqueuelen:1024
>           RX bytes:452010 (441.4 Kb)  TX bytes:519063 (506.8 Kb)
>
> pce.0.1.0 Link encap:Ethernet  HWaddr 00:FF:3A:1A:CB:69
>           UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
>           RX packets:6 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:1333 errors:0 dropped:1079 overruns:0 carrier:0
>           collisions:0 txqueuelen:1024
>           RX bytes:228 (228.0 b)  TX bytes:302530 (295.4 Kb)
>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> tipc-discussion mailing list
> tipc-discussion@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tipc-discussion




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

  reply	other threads:[~2004-08-18 19:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-18 18:35 [uml-devel] tipc in networked UML Randy Macleod
2004-08-18 19:24 ` Jon Maloy [this message]
2004-08-19 19:27   ` [uml-devel] Re: [tipc-discussion] " Randy Macleod

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4123ACEA.6080600@ericsson.com \
    --to=jon.maloy@ericsson.com \
    --cc=macleodr@nortelnetworks.com \
    --cc=tipc-discussion@lists.sourceforge.net \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox