[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rohc] ROHC-FN tutorial: scaled_seq_no compression formula
> However, this was a lot of work to maintain so we abandoned it.
I agree...
> For reference, with real protocols where the operators used are
> non-invertible, look-up tables are very useful (and also fast).
> Although the individual operators used may be many-to-one as with
> modulo, the overall mapping must be one-to-one, so a lookup table is a
> nice solution. Of course scalability is an issue - for this example
> though the tables are small enough to sit in L1 cache so offer a good
> solution. Partly this depends on your architecture, but typically
> modulo consumes a lot of clock cycles.
Thanks, good hint.
br
Klaus
At Fri, 04 Sep 2009 22:15:36 +0100,
Raffles wrote:
>
> [1 <text/html; ISO-8859-1 (7bit)>]
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
> </head>
> <body bgcolor="#ffffff" text="#000000">
> Hi Klaus,<br>
> <br>
> Thanks for the clarification. There is certainly nothing wrong with
> designing the "how" rather than the "what" - the main point is to
> understand that the FN only intends to specify the "what". This is
> intentional, to allow the implementer as much freedom as possible.
> Originally we developed an engine which would take an FN description
> and automatically provide compression and decompression, meaning that
> you could get a reference solution without specifying the "how" part.
> However, this was a lot of work to maintain so we abandoned it.<br>
> <br>
> For reference, with real protocols where the operators used are
> non-invertible, look-up tables are very useful (and also fast).
> Although the individual operators used may be many-to-one as with
> modulo, the overall mapping must be one-to-one, so a lookup table is a
> nice solution. Of course scalability is an issue - for this example
> though the tables are small enough to sit in L1 cache so offer a good
> solution. Partly this depends on your architecture, but typically
> modulo consumes a lot of clock cycles.<br>
> <br>
> Thanks again for the input.<br>
> <br>
> All the best<br>
> <br>
> Raffles<br>
> <br>
> Klaus Warnke wrote:
> <blockquote cite="mid:upra76oc7.wl%25klaus.warnke at acticom.de"
> type="cite">
> <pre wrap="">Hi Raffles,
>
> I tried to implement this encoding:
>
> ENFORCE(sequence_no.UVALUE == (scaled_seq_no.UVALUE * 3) % 16);
>
> I saw, it is easy to calculate the sequence_no.UVALUE from then
> scaled_seq_no.UVALUE, because the formula can be used 1:1.
> But if I want to calculate the scaled_seq_no.UVALUE from the
> sequence_no.UVALUE, I can't see how here.
>
> Did I oversaw something?
>
> So I restructured the formula, which was not so easy to me, because
> there is no inverse for the "%" operator. So I wanted to share this,
> maybe it is helpful for other developers.
>
> </pre>
> <blockquote type="cite">
> <pre wrap="">You specify "what" rather than "how"
> </pre>
> </blockquote>
> <pre wrap=""><!---->My intention was to explain "how", not "what".
> Could you please explain what was wrong about that?
>
> br
> Klaus
>
> At Thu, 03 Sep 2009 21:37:39 +0100,
> Raffles wrote:
> </pre>
> <blockquote type="cite">
> <pre wrap="">Hi Klaus,
>
> Thanks for the post. I think you have probably already seen the
> following line in the example:
>
> ENFORCE(sequence_no.UVALUE
> == (scaled_seq_no.UVALUE * 3) % 16);
>
> Which is to say, a similar function to the one which you have described,
> but expressed in the inverse form. The bindings created by this are two
> way. That is, this single line defines both compression and
> decompression. One of the key principles of the FN is that all bindings
> are two way, so that you only define the profile once for both
> compression and decompression. You specify "what" rather than "how". See
> section 3.2.1 for more details:
> <a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc4997#section-3.2.1";>http://tools.ietf.org/html/rfc4997#section-3.2.1</a>
>
> Thanks for taking the time to read the RFC and send in a post.
>
> If you have any questions feel free to ask.
>
> Regards
>
> Raffles
>
>
> Klaus Warnke wrote:
> </pre>
> <blockquote type="cite">
> <pre wrap="">Hello RoHC'ers 2.0,
>
> the example B.9. in the RFC 4997 ROHC-FN introduces a scaled_seq_no,
> but provides no formula for compression.
>
> Here is my compression formula, maybe it is helpful for other.
>
> scaled_seq_no.UVALUE = (sequence_no.UVALUE + (m*16)) / 3
>
> where m is:
>
> m = 0 if (U%3 == 0)
> m = 2 if (U%3 == 1)
> m = 1 if (U%3 == 2)
>
> Checked with oo calc:
>
> U U%3 m M*16 U+m*16 C=(U+m*16)/3 C*3 U=(C*3)%16
> - --- - ---- ------ ------------ --- ----------
> 0 0 0 0 0 0 0 0
> 1 1 2 32 33 11 33 1
> 2 2 1 16 18 6 18 2
> 3 0 0 0 3 1 3 3
> 4 1 2 32 36 12 36 4
> 5 2 1 16 21 7 21 5
> 6 0 0 0 6 2 6 6
> 7 1 2 32 39 13 39 7
> 8 2 1 16 24 8 24 8
> 9 0 0 0 9 3 9 9
> 10 1 2 32 42 14 42 10
> 11 2 1 16 27 9 27 11
> 12 0 0 0 12 4 12 12
> 13 1 2 32 45 15 45 13
> 14 2 1 16 30 10 30 14
> 15 0 0 0 15 5 15 15
>
> br
> Klaus
> _______________________________________________
> Rohc mailing list
> <a class="moz-txt-link-abbreviated" href="mailto:Rohc at ietf.org">Rohc at ietf.org</a>
> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/rohc";>https://www.ietf.org/mailman/listinfo/rohc</a>
>
>
> </pre>
> </blockquote>
> <pre wrap="">--
> Raffles (Robert Finking)
> m: 0789 463 9887
> e: <a class="moz-txt-link-abbreviated" href="mailto:raffles at gluft.com">raffles at gluft.com</a>
> w: gluft.com
>
> O O
> OOOOOO O O O OOOOOO OOOOO
> O O O O O OOOOO O
> OOOOOO O OOOOOO O O
> OOOOOO
> we care about software
>
> -----------------------------------------------------------------
> Gluft Ltd. Registered No.: 6795336
> The information contained in this e-mail and any attachments is
> proprietary to Gluft Ltd and must not be passed to any third
> party without permission. This communication is for information
> only and shall not create or change any contractual relationship.
> Please consider the environment before printing. Thank you.
> -----------------------------------------------------------------
>
> _______________________________________________
> Rohc mailing list
> <a class="moz-txt-link-abbreviated" href="mailto:Rohc at ietf.org">Rohc at ietf.org</a>
> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/rohc";>https://www.ietf.org/mailman/listinfo/rohc</a>
> </pre>
> </blockquote>
> <pre wrap=""><!---->_______________________________________________
> Rohc mailing list
> <a class="moz-txt-link-abbreviated" href="mailto:Rohc at ietf.org">Rohc at ietf.org</a>
> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/rohc";>https://www.ietf.org/mailman/listinfo/rohc</a>
>
> </pre>
> </blockquote>
> <br>
> <pre class="moz-signature" cols="72">--
> Raffles (Robert Finking)
> m: 0789 463 9887
> e: <a class="moz-txt-link-abbreviated" href="mailto:raffles at gluft.com">raffles at gluft.com</a>
> w: gluft.com
>
> O O
> OOOOOO O O O OOOOOO OOOOO
> O O O O O OOOOO O
> OOOOOO O OOOOOO O O
> OOOOOO
> we care about software
>
> -----------------------------------------------------------------
> Gluft Ltd. Registered No.: 6795336
> The information contained in this e-mail and any attachments is
> proprietary to Gluft Ltd and must not be passed to any third
> party without permission. This communication is for information
> only and shall not create or change any contractual relationship.
> Please consider the environment before printing. Thank you.
> -----------------------------------------------------------------
> </pre>
> </body>
> </html>
> [2 <text/plain; us-ascii (7bit)>]
> _______________________________________________
> Rohc mailing list
> Rohc at ietf.org
> https://www.ietf.org/mailman/listinfo/rohc