Re: [riot-devel] To global seed or not to global seed
>> In contrast to the current procedure of having a global state, we rather >> should opt to allow local states for each thread (not excluding a global >> state). > > Is testing and simulation the only use case you can imagine? I'm somewhat > reluctant to add code just for non-production purposes. Deterministic PRNGs can also be used for the implementation of certain MAC protocols for instance in channel assignment (e.g. frequency hopping schedule, time slot assignment). Cheers, Daniel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] To global seed or not to global seed
On Mit, 2017-03-08 at 09:09 +0100, Kaspar Schleiser wrote:
> Hey,
>
> On 03/08/2017 12:18 AM, Cenk Gündoğan wrote:
> >
> > we rather
> > should opt to allow local states for each thread (not excluding a global
> > state).
> Interesting. Up to now our trouble with RNGs was mostly on how to make
> them more random. Now we're trying to make them predictable. What's your
> use case for that?
Using the random numbers for a stream cipher, for instance.
> How about an interface a la
>
> rand_init_(rnd__t *rnd);
> rand_seed32(rnd_t *rnd, uint32_t);
> rand_seed(rnd_t *rnd, const uint8_t *in, size_t len);
> rand_get(rnd_t *rnd, uint8_t *out, size_t n);
> rand_get32(rnd_t *rnd);
>
> typedef struct {
>
> } rnd_t;
>
> typedef struct {
> rnd_t rnd;
> ;
> } rnd_tinymt32_t;
>
> That way we'd have:
>
> - user controlled state
> - the ability to overload (e.g., combine hwrng, collected entropy, prng
> but with the same interface)
>
Look good, imo.
cheers
Mathias
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] To global seed or not to global seed
Hi Oleg, Ludwig, On 08.03.2017 10:30, Oleg Hahm wrote: Hi Ludwig! On Wed, Mar 08, 2017 at 10:28:13AM +0100, Ludwig Knüpfer wrote: Am 8. März 2017 10:21:15 MEZ schrieb Oleg Hahm : Is testing and simulation the only use case you can imagine? I'm somewhat reluctant to add code just for non-production purposes. Since we outspokenly target researchers with RIOT this is a production feature. However we might want to move this feature into a dedicated implementation of the same interface. Thanks, that was more or less what I meant. I'm not sure whether we 'over-complicate' the issue. There are good PRNGs with state space of one (or very few) int, call it seed. So if this function is called as 'rand(seed)', rand can be stateless ... and seed is allocated memory of the application. Seeds could be initially generated by 'random_init(seed)'. At the same time, one can overload with a stateful 'rand()' which is auto-initialized and convenient ... and for those who don't care for more control. IMO, this would not need a 'random_init()' user call. Cheers, Thomas Btw: David Jones (UCL Bioinformatics) writes "Rule #1: Do not use system generators. ... Almost all of these generators are badly flawed. Even when they are not, there is no guarantee that they were not flawed in earlier releases of the library." -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] To global seed or not to global seed
Hi Ludwig! On Wed, Mar 08, 2017 at 10:28:13AM +0100, Ludwig Knüpfer wrote: > Am 8. März 2017 10:21:15 MEZ schrieb Oleg Hahm : > >Is testing and simulation the only use case you can imagine? I'm somewhat > >reluctant to add code just for non-production purposes. > > Since we outspokenly target researchers with RIOT this is a production > feature. > > However we might want to move this feature into a dedicated implementation > of the same interface. Thanks, that was more or less what I meant. Cheers, Oleg -- The problem with TCPIP jokes is that when I tell them, all I want is an ACK but usually get FINs and RSTs signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] To global seed or not to global seed
Hi, Am 8. März 2017 10:21:15 MEZ schrieb Oleg Hahm : >Is testing and simulation the only use case you can imagine? I'm >somewhat >reluctant to add code just for non-production purposes. Since we outspokenly target researchers with RIOT this is a production feature. However we might want to move this feature into a dedicated implementation of the same interface. Cheers, Ludwig ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] To global seed or not to global seed
Hi, Am 8. März 2017 10:06:17 MEZ schrieb "Cenk Gündoğan" : >On 17-03-08 09:09:34, Kaspar Schleiser wrote: >> That way we'd have: >> >> - user controlled state >> - the ability to overload (e.g., combine hwrng, collected entropy, >prng >> but with the same interface) > >Looks good at first sight. We also would need some sort of >synchronization for concurrent access, e.g. a mutex in the `rnd_t` >struct, if two threads should use the same local state. Just as a remark (might make sense to copy and paste to upcoming documentation): If two threads are using the same local state they will probably not get deterministic numbers. Cheers, Ludwig ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] To global seed or not to global seed
Dear Cenk, thanks for bringing up this discussion. On Wed, Mar 08, 2017 at 12:18:28AM +0100, Cenk Gündoğan wrote: > 1) we can define it as BCP to *not* use `random_init()` if `auto_init` >is used >=> it's hard to guarantee a one-time call to `random_init()` as human >do surely err (especially if several nested modules are involved). Basically, we have similar problems for other modules that should (or even must) not be initialized twice. So far, my/our take on this was to document this rather than programmatically prevent this. The memory overhead is small, but existent, the runtime overhead is probably negligible for a function that should not be called more than once. > In contrast to the current procedure of having a global state, we rather > should opt to allow local states for each thread (not excluding a global > state). Is testing and simulation the only use case you can imagine? I'm somewhat reluctant to add code just for non-production purposes. Cheers, Oleg -- /* vsprintf.c -- Lars Wirzenius & Linus Torvalds. */ * * Wirzenius wrote this portably, Torvalds fucked it up :-) */ linux-2.2.16/lib/vsprintf.c signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] To global seed or not to global seed
Hey, On 03/08/2017 10:06 AM, Cenk Gündoğan wrote: > >> How about an interface a la >> > Looks good at first sight. We also would need some sort of > synchronization for concurrent access, e.g. a mutex in the `rnd_t` > struct, if two threads should use the same local state. Do we need that kind of synchronization if all state is localized in the overloaded rnd_t, at that level? Applications *seeding* the same state in multiple threads will be rare and can synchronize externally. Whether "reading" from the rng needs to be synchronized should be up to the RNG implementation. Kaspar signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] To global seed or not to global seed
Heyho,
On 17-03-08 09:09:34, Kaspar Schleiser wrote:
> Hey,
>
> On 03/08/2017 12:18 AM, Cenk Gündoğan wrote:
> > we rather
> > should opt to allow local states for each thread (not excluding a global
> > state).
>
> Interesting. Up to now our trouble with RNGs was mostly on how to make
> them more random. Now we're trying to make them predictable. What's your
> use case for that?
>
Well .. PRNGs are predictable with enough knowledge (algorithm used +
seed) and an enthusiastic observer (or someone who reached divine
omniscience) can even derive numbers by looking at the sequence across
several runs and constant seeds. The trouble, IMO, is seeding those
PRNGS randomly, but that's not what I wanted to focus on in this mail.
Sorry, if I gave this kind of impression.
My point is: a user application may need a specific seed to have a
deterministic sequence (especially interesting for simulation/testing).
And such determinism is removed from the application's POV, if NDP, RPL,
or TCP are also advancing the pointer in the sequence.
> How about an interface a la
>
> rand_init_(rnd__t *rnd);
> rand_seed32(rnd_t *rnd, uint32_t);
> rand_seed(rnd_t *rnd, const uint8_t *in, size_t len);
> rand_get(rnd_t *rnd, uint8_t *out, size_t n);
> rand_get32(rnd_t *rnd);
>
> typedef struct {
>
> } rnd_t;
>
> typedef struct {
> rnd_t rnd;
> ;
> } rnd_tinymt32_t;
>
> That way we'd have:
>
> - user controlled state
> - the ability to overload (e.g., combine hwrng, collected entropy, prng
> but with the same interface)
Looks good at first sight. We also would need some sort of
synchronization for concurrent access, e.g. a mutex in the `rnd_t`
struct, if two threads should use the same local state.
Cheerio!
Cenk
>
> Kaspar
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] To global seed or not to global seed
Hey,
On 03/08/2017 12:18 AM, Cenk Gündoğan wrote:
> we rather
> should opt to allow local states for each thread (not excluding a global
> state).
Interesting. Up to now our trouble with RNGs was mostly on how to make
them more random. Now we're trying to make them predictable. What's your
use case for that?
How about an interface a la
rand_init_(rnd__t *rnd);
rand_seed32(rnd_t *rnd, uint32_t);
rand_seed(rnd_t *rnd, const uint8_t *in, size_t len);
rand_get(rnd_t *rnd, uint8_t *out, size_t n);
rand_get32(rnd_t *rnd);
typedef struct {
} rnd_t;
typedef struct {
rnd_t rnd;
;
} rnd_tinymt32_t;
That way we'd have:
- user controlled state
- the ability to overload (e.g., combine hwrng, collected entropy, prng
but with the same interface)
Kaspar
signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
