Re: [MirageOS-devel] mirageos 3.0 : let's break some APIs

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

Thomas,

[there's no need to reply to my mail address, please just keep the
mailing list in the to; thx]

On 17/06/2016 16:11, Thomas Leonard wrote:
> On 17 June 2016 at 14:38, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
>> On 17/06/2016 11:26, Mindy wrote:
>> For the TCP sublibrary, I suspect that removing all the floats and calls
>> to Clock.now () will improve speed noticeable.
> 
> Some benchmarks would be good here. My guess is that the extra
> indirection of an int64 would outweight the slowness of the FPU, but
> it's only a guess. I doubt it makes much difference.

not sure where are int64?  an OCaml int should be wide enough for TCP
timings (in nsec).

> Concete delays (that go via an abstract TIME module) don't have to be
> bad for testing. You just pass a clock that instantly moves forward to
> the next scheduled event. See e.g. this test clock here:

I disagree.  For me, having a tick frequency specified (let it be 1s)
and then counting the ticks (for an arp timeout 150) is much clearer
than getting your current absolute time, adding n seconds, and comparing
whether you're active at a future point.

> Something has to decide:
> 
> - how long to sleep the unikernel
> - what to do when it wakes
> 
> I don't see any reason why the scheduler should be worse at this that
> the TCP stack. Presumably both would use a priority queue.
> 
> You might get a more compat representation by having e.g. an array of
> packets and their timeouts, but then you'd have to keep searching the
> array.

My point is still about which parts of a protocol you can implement in a
pure way, and which need side effects.  Sleep is side effecting, thus
having it outside [the TCP state machine] is in my opinion an improvement.

> Sounds fine, although it might complicate the code in some places (and
> if you return the time you want it to wait for and a callback to
> invoke when done then you're just reimplementing Lwt, although
> possibly making it clearer that there are fewer effects besides
> waiting).

Did you look at the charrua code?  There's no need to "return the time
you want".  I mentioned this mechanism since it is elegant and does not
install any timers on its own, but acts only if there's anything else to
do anyways (such as incoming packets).

> Wouldn't updating all these counters be really slow? And what stops
> the ticks when the VM should go to sleep?

I don't understand what you mean.  If the VM goes to sleep the external
on_timer event generator no longer pushes events.

> This is much more efficient that inserting millions of tick events.

Depending on your library or application, you can select the tick
interval.  As mentioned, I don't propose that this tick event stream is
suitable for all scenarios (e.g. if you want to implement at or cron, it
might be worth to have some on_timer).


hannes

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel