Re: Bandwidth distribution per ip

[Denys Fedoryshchenko <denys () visp net lb>]

On 2017-12-20 19:12, Saku Ytti wrote:
> On 20 December 2017 at 19:04, Denys Fedoryshchenko <denys () visp net lb> 
> wrote:
>
> > As person who is in love with embedded systems development, i just 
> > watched
> > today beautiful 10s of meters long 199x machine, where multi kW VFDs 
> > manage
> > huge motors(not steppers), dragging synchronously and printing on thin 
> > paper
> > with crazy speed and all they have is long ~9600 link between a bunch 
> > of
> > encoders
> > and PLC dinosaur managing all this beauty. If any of them will apply a 
> > bit
> > wrong
> > torque, stretched paper will rip apart.
> > In fact nothing complex there, and technology is ancient these days.
> > Engineers who cannot synchronize and update few virtual "subinstances"
> > policing ratio based on feedback, in one tiny, expensive box, with
> > reasonable
> > update ratio, having in hands modern technologies, maybe incompetent?
>
> As appealing it is to say everyone, present company excluded, is
> incompetent, I think explanation is more complex than that. Solution
> has to be economic and marketable. I think elephant flow detection and
> unequal mapping of hash result to physical interface is economic and
> marketable solution, but it needs that extra level of abstraction,
> i.e. you cannot just backport it via software if hardware is missing
> that sort of capability.
Even highly incompetent in such matters person as me, know, that some of
modern architecture challenges is when NPU consists of a large number of
"processing cores", each having his own counters, and additionally it 
might
be also multiple NPU handling same customer traffic. On such conditions
updating _precise_ counters(for bitrate measurements, for example) is 
not
trivial anymore as sum = a(1) + .. + a(n), due synchronization, shared 
resources
access and etc.
But still it's solvable in most of cases, even dead wrong way of running 
script
and changing policer value on each "unit" once per second mostly solve 
problem.
And if architecturally some NPU cannot do such job, it means they are 
flawed,
and should be avoided for specific tasks, same as some BCM chipset 
switches
with claimed 32k macs, but choking from 20k macs, because of 8192 
entries tcam and
probably imperfect hash + linear probing on collision. Sure such switch 
is not
suitable for aggregation and termination.
Still, i am running some dedicated servers on colo in EU/US, some over 
10G(bonding),
and _single_ ip on server, i never faced such balancing issues, thats 
why i am asking,
if someone had such carrier, who require to balance bandwidth between 
many ips,
with quite high precision, to not lose expensive bandwidth.