Re: CVS commit: src/sys/net

[Roy Marples <roy%marples.name@localhost>]

On 17/02/2016 09:02, Ryota Ozaki wrote:
>> So what events would you choose to skip, if not the scheme that Roy
>> described?
> 
> (I think I confused you, sorry...)
> 
> I rather want to not skip anything as much as possible
> (except for repeating same events (e.g., up/up/up) because
> keeping them all changes the original behavior).
> 
> I intend to skip/eliminate events only if there are too many
> events happen in a short period (i.e., need queuing) to protect
> the system from overloading. In that case (it's a very rare case
> I think), we just drop an earliest event first.

How much is too many and what is a short period?
Once you start skipping/eliminating events, how is your solution any
better? How do you measure some lossage vs some lossage?

Also, we can't just drop the earliest event first - we have to ensure
that each state is left in the queue.
Consider starting in UP:
DOWN/UNKNOWN/UP/UNKNOWN/UP/UNKNOWN/UP

We cannot just discard the fact it went down because important events
attached to DOWN won't trigger.

Lastly, have we considered the system could be overloaded due to so many
link state change events? A longer queue or more complicated would only
make this worse.

From an earlier post of yours:
> Even if a UP state is transient, it's an event that may provide us a 
> hint of network conditions for diagnostic. We may be able to get it 
> from the console output, but it's not so convenient; we need to
> track events via two different facilities.

If you're skipping/eliminating events as well then you would also need a
second facility to record this. Other than scribbling on the console,
what did you have in mind? Could this be used elsewhere in the system
where equvialent network assertations are recorded?

Roy