Regarding transmissions spanning a slot…it’s potentially multiple slots. If the max MAC frame size is 1500 bytes. At the worst case 50 kbps, that would be ~242 ms to send the frame - given a 10ms slot, thats 24 slots, or at 25 ms slots, that’s still almost 10 slots — The average packet size on our network is somewhat less, but for “bulk” types of traffic ( like network-wide firmware update scenarios ) it’s a problem, although this happens at higher bit-rates so it’s not as bad as 50kbps.
Randy > On Dec 13, 2016, at 10:34 AM, Randy Turner <[email protected]> wrote: > > Hi Pascal, > > That was the other alternative on the call I was referring to, if a node > (application) requires spanning a slot for TX, then an > application/context-based cell scheduling algorithm would just schedule > adjacent cells ( on the same channel )— but this is just one alternative, > there are probably other considerations…I’m still studying scheduling > documents. > > R. > > >> On Dec 13, 2016, at 10:18 AM, Pascal Thubert (pthubert) <[email protected] >> <mailto:[email protected]>> wrote: >> >> Seems that large EBs at low rates ended up being a problem in subgig cases >> after all, Dale. >> >> The discussion at the interim was either to make very large slots => >> impractical, or preconfigure sometimes, 2 or more consecutive time slots are >> paired; the second is never scheduled, and is free to accept the remainder >> of the frame sent in the first… The pairing will be interesting to make >> work, ince the channel computation is based on ASN so the consecutive time >> slots to not have the same channel offset…. >> >> Cheers >> >> Pascal >> >> >> >> From: 6tisch [mailto:[email protected] >> <mailto:[email protected]>] On Behalf Of Thomas Watteyne >> Sent: vendredi 9 décembre 2016 15:39 >> To: Dale R. Worley <[email protected] <mailto:[email protected]>> >> Cc: Randy Turner <[email protected] >> <mailto:[email protected]>>; [email protected] <mailto:[email protected]> >> Subject: Re: [6tisch] slot schedluing >> >> Dale, >> >> +1 on your answer. >> >> Thomas >> >> On Thu, Dec 8, 2016 at 9:38 PM, Dale R. Worley <[email protected] >> <mailto:[email protected]>> wrote: >> Randy Turner <[email protected] <mailto:[email protected]>> >> writes: >> > Just re-confirming an assumption -- from a TSCH perspective, slot >> > scheduling assumes any single transmission "cannot" exceed a slot >> > boundary -- if transmissions require a certain amount of time, then the >> > slot width is increased to deal with this ( or possibly increase the >> > TX bit rate if possible ) >> > >> > Is this correct ? >> >> As others have noted, extending the slot width can only be done when the >> network is initialized. In practice, packets that do not fit within a >> slot time are fragmented. My understanding is that all such packets are >> IP packets, and are fragmented using using the layer 2 fragmentation >> defined in RFC 6282 (not the one defined in RFC 4944). Thus, the >> minimum (layer 3) IPv6 MTU of 1280 bytes is supported. >> >> As far as I know, there is no fragmentation mechanism for the EB >> (extended beacon) layer-2 packets. But that does not seem to be a >> problem in practice. >> >> Dale >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/6tisch >> <https://www.ietf.org/mailman/listinfo/6tisch> >> >> >> >> -- >> _______________________________________ >> >> Thomas Watteyne, PhD >> Research Scientist & Innovator, Inria >> Sr Networking Design Eng, Linear Tech >> Founder & co-lead, UC Berkeley OpenWSN >> Co-chair, IETF 6TiSCH >> >> www.thomaswatteyne.com <http://www.thomaswatteyne.com/> >> _______________________________________ >> _______________________________________________ >> 6tisch mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/6tisch >> <https://www.ietf.org/mailman/listinfo/6tisch> > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
