[Ardour-Dev] Banking on a surface

Fri Jun 24 11:42:10 PDT 2016

Sorry but with some mentions you are not right.

default full ethernet is 1518 = 1514 ethernet2 header +4 bytes checksum
GRE tunnel MTU is 1476 = 1500 - (20 bytes IP header + 4 bytes GRE Header) (
similar to ADSL in Europe)
MPLS 1492 if not configured

Next thing is if going over the inet it also makes a difference if using
Juniper or Cisco which can badly affect the performance of the network
segmentation of packages will be the result. This can also force the
computer to do discovery of max_package_size where it sends normal data
while trying to determine how big the packages can be ( as you might guess
not good for fast streams).

The actual BGP protocol is adding to the MTU of 1518 another 8bytes filling
the missing bytes with zero to make parsing faster( here we Talk 40G to 80G
switching between AS).

I would not want to send something as OSC over the inet so we stay with the
normal ethernet2 spec on a local Network ;)

With nics you have to differentiate a bit more. Yes the Linux kernel is
able to do very fast networking myself running Servers at work that do 4G
networking and some systems with even 40G. But that is far from standard
and needs heavy modification of MII and GMII between CPU and phys_ether IC
( that`s the part of the network card where it goes to the Ethernet slot in
the back of the PC for those unknown to this and reading it). Wont do  deep
dive into this except to say it is OSI layer 1 ;)

In the end to get the Fastest ethernet performance possible with standard
setting is to stay below the MTU of ethernet and ADSL and the like meaning
packages should not be bigger than 1476 bytes to prevent segmentation which
slows down and is well in the range of all possibilities if uncertain it is
usually the best to stay with the defaults.

2016-06-24 19:39 GMT+02:00 Len Ovens <len at ovenwerks.net>:

> On Fri, 24 Jun 2016, Melanie Bernkopf wrote:
>
> Yes bundles might bring in a bit of latency but I suspect that in the case
>> of a
>> bank change it would be OK or less than surface setting everything to
>> zero and
>> waiting for updates. Anyways a bit of latency is allways there and at
>> work we
>>
>
> If I was to set up bundling, it would always be there, not just bank
> change. (assuming no extra duplcate code) This is because, I would que them
> and send on a timed basis... there may be a better way, but I am not seeing
> it right now.
>
> once traced out the difference between 10M 100M 1G 10G networks an their
>> latency
>> it was quite surprising to see that they are in that way all the same.
>> what makes
>> a big difference is UDP and TCP the later being a bit slower ( but
>> possible to
>> bring to the same speed with deep kernel hacks). In the end well 10M is
>> not up to
>> date 100M is okay for a control Surface I think 1G being better but either
>> expensive or using strange standards.
>>
>
> GB networks will use (in a linux net) 100m standards for packet size if
> the network is set that way. One actually has to set up for over size
> packets and then they are only local as the Inet runs at 1500 anyway. A lot
> of systems come with GB on the board, even the small arm boards like the
> odroid. The difference between single messages is that single messages are
> (so far as I know) one to a packet. Bundles are a group of messages to a
> packet. The bundle, netwise, will take less time/bandwidth to move as each
> bundle has only one packet overhead to deal with. If the lib is smart it
> would do this on its own. (check if there are more than one message in the
> queue, send them all in one packet) Like wise, on receiving a bundle, the
> lib should break it down into messages as far as the application is
> concerned.
>
> I am thinking that there are places I could bundle things. For example, if
> the smae info is being sent to both a strip and a select/expand strip
> (expand is a new concept I am working on) then bundle makes sense. Track
> name, no of input, no of outputs and track comment are always sent
> together... another bundle possibility. In these cases there would be a
> latency reduction by using bundles as well as a network traffic reduction
> and so worth while. This is down the road though as I have bigger "fish to
> fry" right now.
>
> In the end I see two questions that would sum it up:
>>
>> What gives the least latency?
>> What is the least work to implement?
>>
>> Second question is maybe more important because it is the same amount of
>> data to
>> be transfered which leaves the main source of latency to the
>> Microcontroller in
>> the surface and how fast it can handle things (again up to the surface
>> designer
>> ;) ).
>>
>
> Both are important. Tied to latency is net bandwidth, which is finite. The
> next big change in audio is likely to be AoIP. Linux could be at the front
> of all this and the reality is that there are Linux bits of code out there,
> but no one is putting it together. AES67 has come but no one has written
> open linux drivers for it... and for the most part this is a HW thing...
> PCs do not come with a NIC that can do a good job of it. So laptops can't
> use it... a Mac can by the way. AVB is here now too. Motu is making nice
> AVB boxes that do work with a Mac (the new Macs come with AVB built in). In
> the PC world these show up as a USB gateway to AVB :P  But this will
> change, and then using extra BW on the net is not a good thing. The intel
> i210 NICs are not that expensive for a desktop so maybe we will see
> something soonish.
>
> Long Text again but the conclusion would be if it is working allready
>> leave it
>> that way
>>
>
> Yes... and no. Improvements are always good :)  I will leave the banking
> layout as is (always fill) unless there is a large outcry for something
> different.
>
> not confusing people. But you should also decide where to draw the line of
>> what
>> ardour is doing and what is better to be done on the surface or app. If
>> banksize
>> is set just send that amount of strips if not set send all and leave it
>> to the
>> other side to deal with it (sounds quite rude but that would be the line
>> I would
>> draw on that matter).
>>
>
> There are defaults:
>         - no feedback
>         - no bank
>         - available strips includes inputs, buses and VCAs
>         - master/monitor are separate
>
> If the surface wants something different it has to tell Ardour about that
> using /set_surface or /set_surface/*. It looks like there will also be some
> preset profiles like maybe /ttc-2 for example which would just be like
> sending /set_surface iiii but with just an on/off parameter. These are easy
> to set up so long as the setup is already possible with /set_surface
>
>
>
> --
> Len Ovens
> www.ovenwerks.net
>
> _______________________________________________
> ardour-dev mailing list
> ardour-dev at lists.ardour.org
> http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/pipermail/ardour-dev-ardour.org/attachments/20160624/da45e860/attachment-0001.htm>