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

[Thomas Leonard <talex5@xxxxxxxxx>]

On 17 June 2016 at 15:44, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
> Thomas,
>
> [there's no need to reply to my mail address, please just keep the
> mailing list in the to; thx]

Hmm, this is the default behaviour for gmail at least.

> 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).

At 31 bits, you can only represent intervals up to 2.1s with a native
integer (on arm32 at least). That said, floats are often boxed too.

>> 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.

For that case, you'd just do `Time.sleep n` (as in `pick [event;
Time.sleep n]`).

[ unsnip
>>> I've no detailed insight into the scheduler, but my intuition is that
>>> adding an enormous amount of sleepers (e.g. for each
>>> maybe-to-be-retransmitted frame) does not scale.
]
>> 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.

Sure, I was replying to your comment about performance.

>> 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).

I assue you're talking about this code:

let tick () =
  Lwt_unix.sleep 5. >|= fun () ->
  Some `Tick

let timer_stream = Lwt_stream.from tick in
...

But this doesn't allow the VM to sleep when there is nothing left to
do; it will go on waking up every 5 seconds forever.

>> 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.

I mean, the ticks will prevent it from sleeping for long.

>> 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).


-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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