Re: Netjack1, transport sync and tempo

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux