On 04/26/2010 09:04 AM, Aurelien wrote: > On Thu, Apr 15, 2010 at 07:50:12PM -1000, david wrote : >> Aurelien wrote: >>> On Fri, Apr 16, 2010 at 02:37:42AM +0200, torbenh wrote : >>>> On Thu, Apr 15, 2010 at 08:34:11AM +0200, Aurelien wrote: >>>>> Hello, >>>>> >>>>> I'm always hesitating between netjack1/2. >>>>> >>>>> Considering netjack1 and sync transport. I works fine, but I would like >>>>> the master to set the tempo for the slave(s), and it looks like netjack1 >>>>> does not that (in the jackdmp version, at least). Am I wrong? Is there a >>>>> way to get the tempo from master to slave? >>>> no. you definitely need a transportmaster on the slave. >>> >>> OK. >>> This gives another point to netjack2! >>> >>> Concerning my problems with my network, it finally seems like both my >>> gigabit ethernet cards (Atheros Attansic L1) works in .... 10MB!!! That >>> should explain why I get these offset of 3 to 16 (!!!) cycles! >>> >>> It's weird, as the card is supported by the kernel, and lshw tells it >>> works at 1GB, but however, rate is around 10MB and lower. >> >> Hmmm - you don't happen to have your gigabit cards connected via a >> non-gigabit router/switch? Faster cards will usually happily connect at >> slower speeds if that's the best something along the way can do ... >> > > No router, no switch, just two machines with the very same ethernet card > and distribution and kernel linked one to the other. > Actually, I've checked by monitoring network with iptraf. The result is > clear : > scp => transfer rate ~= 1Gb/s > netjack2 => transfer rate < 20Mb/s it's not totally surprising. low latency at low channel counts is not very efficient. say you want a frame size of 64, then there are only 64 frames in each network packet, too. if you're only using two channels, that's 64 * 4 * 2 = 512 bytes in each packet (for optimum network saturation, you'd use jumbo frames at 16 or 32k..). many small chunks, lots of work. otoh, scp (or any other traffic where absolute low latency does not matter) will happily fill up the MTU and generate way less housekeeping work for the kernel. try increasing the channel count and the fragment size, then you should be able to saturate your network eventually. of course, latency will be higher, too. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
