Cantankerous old buffer

I suppose the question is does it ever run out?

Is the buffer level for internet radio or for upnp music. If the latter, do you use a switch, or is everything connected to their router?

Upnp is internal.  Streaming from my server is no problem.  It happens when streaming HD radio.  The bandwidth I have is many, many times in excess of what is needed to stream HD radio.  Indeed, connected to the same switch, my PC streams HD video from Netflix.  Switches are used, yes.  But as I say, nothing has changed since my previous broadband connection of 14MBs.  Now it is many times faster, the buffer responds by becoming worse.  As I say, what gives?

Nothing gives really there could be a host of reasons from different DNS settings to coincidence, to server pressures. Whats important is if you get drop outs, if you don't then don't sweat it.

I am not sure that 100% buffering is what the firmware of the UQ has been designed to always strive for. But if this was the case, your observations would indeed be a bit puzzling. On the other hand, maybe the firmware recognizes that, as your connection has improved, there is less need for buffering. Who knows? What happens if you resume normal settings for the Qute in your router?

Total guess here but maybe the unit has some idea of available bandwidth and if it's relatively high it doesn't try to fill the buffers because of the low latency.

Hi, you need focus less on bandwidth, but more on latency... having loads of bandwidth does not improve latency across the Internet... latency can often be our enemy.. far more so than bandwidth..(i bet in the consumer space over the next 5 years or so you will see consumer ISP differentiation based more on latency to popular services rather than bandwidth)

Effective TCP buffer sizing  can often be determined by network round trip delay or latency.

if the buffer stays at 70% you are fine.. If it oscillates you have the start stop syndrome... and you might actually find using a wifi connection improves things. (Kind of like variable speed controls on busy motorways). In private commercial networks a technique called WRED is often used that deliberately drops data to control TCP window buffers to avoid stop start... on the public internet we don't have this luxury so we have to mitigate at each end often within the server/clients.

Naim are testimg a new firmware that should improve operability here by reducing Naim TCP stack latency, so with the next firmware you might notice your buffer goes to 100% or then again....

Simon

A lot of folk struggle to understand most of this,  more so some of the technical terms.  I found this reasonably simple explanation of the association & differences of bandwidth & latency ........  http://www.dslreports.com/faq/694

The main thing I think best to understand is bandwidth itself doesn't improve data throughput - ie the quality of the timing of the packets of data being transported through the network. However latency does indeed in part affect this quality.

Latency or more typically Round Trip Delay is the time it takes for a packet to go in one direction end to end transported across the network and the time it takes to be transported end to end back across the network. (These timings in our case here also need to include the timings in the protocols stacks of the devices at either end)

Low or varying times will produce generally a low quality transfer of data - especially for streaming etc

Its a case of never mind the width - you need to feel the quality... that is a high bandwidth internet connection will not necessarily improve the quality of the transfer if the underlying latency is poor.. or in other words a cheap bling sound system boasting 100W PMO may well sound inferior to a quality 20W RMS hifi amplifier.

So what can drive varying latency - well every step in the network can - device processor load, local network, access network and internetwork. Typically though on a home network with a high 'speed' access - it will be the connections into the internet and the peering arrangements and the congestion thereof that will affect this timing - also we have seen Tidal have been optimising the packet timing their end - and indeed Naim are optimizing their packet timing in new firmware that they are developing.

Mike good link for terms - but perhaps gets into more detail than we need on this forum at least to explain this... but I am only a simple soul

....     .....      .....   .......

stop stop  ......   falling over clutching sides

Lol, what ever can you mean 

Let this thread laps somewhat.  Been busy.  Very impressed with the comments: thanks folks.

I will follow up this 'latency' thing and find out if there is anything I can do to mitigate it.  I have been aware of its existence for some time but never thought it was something that I would have any control over.  I confess that it makes rather a mockery of these 'super fast' broadband connections if they all have latency built in which can render them all a bit pointless.  Hey-ho, life is never simple!