<div dir="ltr"><div><div><div><div><div><div><div><div>Sorry but with some mentions you are not right.<br><br></div>default full ethernet is 1518 = 1514 ethernet2 header +4 bytes checksum<br></div>GRE tunnel MTU is 1476 = 1500 - (20 bytes IP header + 4 bytes GRE Header) ( similar to ADSL in Europe)<br></div>MPLS 1492 if not configured<br><br></div>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).<br><br></div>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).<br><br></div>I would not want to send something as OSC over the inet so we stay with the normal ethernet2 spec on a local Network ;)<br><br></div>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 ;)<br><br></div>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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-24 19:39 GMT+02:00 Len Ovens <span dir="ltr"><<a href="mailto:len@ovenwerks.net" target="_blank">len@ovenwerks.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 24 Jun 2016, Melanie Bernkopf wrote:<br>
<br>
</span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes bundles might bring in a bit of latency but I suspect that in the case of a<br>
bank change it would be OK or less than surface setting everything to zero and<br>
waiting for updates. Anyways a bit of latency is allways there and at work we<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
once traced out the difference between 10M 100M 1G 10G networks an their latency<br>
it was quite surprising to see that they are in that way all the same. what makes<br>
a big difference is UDP and TCP the later being a bit slower ( but possible to<br>
bring to the same speed with deep kernel hacks). In the end well 10M is not up to<br>
date 100M is okay for a control Surface I think 1G being better but either<br>
expensive or using strange standards.<br>
</blockquote>
<br></span>
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.<br>
<br>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the end I see two questions that would sum it up:<br>
<br>
What gives the least latency?<br>
What is the least work to implement?<br>
<br>
Second question is maybe more important because it is the same amount of data to<br>
be transfered which leaves the main source of latency to the Microcontroller in<br>
the surface and how fast it can handle things (again up to the surface designer<br>
;) ).<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Long Text again but the conclusion would be if it is working allready leave it<br>
that way<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
not confusing people. But you should also decide where to draw the line of what<br>
ardour is doing and what is better to be done on the surface or app. If banksize<br>
is set just send that amount of strips if not set send all and leave it to the<br>
other side to deal with it (sounds quite rude but that would be the line I would<br>
draw on that matter).<br>
</blockquote>
<br></span>
There are defaults:<br>
- no feedback<br>
- no bank<br>
- available strips includes inputs, buses and VCAs<br>
- master/monitor are separate<br>
<br>
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<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
--<br>
Len Ovens<br>
<a href="http://www.ovenwerks.net" rel="noreferrer" target="_blank">www.ovenwerks.net</a><br>
<br>
_______________________________________________<br>
ardour-dev mailing list<br>
<a href="mailto:ardour-dev@lists.ardour.org" target="_blank">ardour-dev@lists.ardour.org</a><br>
<a href="http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org" rel="noreferrer" target="_blank">http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org</a><br>
</div></div></blockquote></div><br></div>