Subject: RE: [rohc] Torture test - 2.10. INPUT-BITS

From: "Lajos Zaccomer (ETH)" <[email-masked]>
Date: Fri, 17 Jan 2003 16:06:32 +0100

Hi,

My result differs from what is given in the draft

	0x0000 0002 0002 0013 0000 0003 001a 0038	

by the exclamation mark:
	
	0x0000 0002 0002 0013 (!) 0001 0006 000c 000d 0003

0x932e = (10)(0100)(110010)!(1)(110  

There input_bit_order = 1, i.e. P=1. Then it should input 1 bit of value 1 to the LSB of address 71, as a result of which the OUTPUT will be 0001.

Am I mistaken?

BR/Zacco

-----Original Message-----
From: Price, Richard [mailto:[email-masked]]
Sent: Friday, January 17, 2003 3:43 PM
To: 'Lajos Zaccomer (ETH)'; [email-masked]
Subject: RE: [rohc] Torture test - 2.4. SHA-1

Hi,

For this particular test we deliberately use more than the
default number of UDVM cycles. It's important to test the SHA-1
instruction with the largest possible input size of 65535 bytes
(e.g. to make sure that it doesn't cause any buffers to overflow),
which means that the total cost of the test must be at least 2^16
UDVM cycles.

Would it be useful to have a note in the draft pointing out that
since the test needs a total of 66327 UDVM cycles, it must be
executed with a cpb of at least 32?

Regards,

Richard

> -----Original Message-----
> From: Lajos Zaccomer (ETH) [mailto:[email-masked]]
> Sent: Friday, January 17, 2003 11:08 AM
> To: [email-masked]
> Subject: [rohc] Torture test - 2.4. SHA-1
>
>
> Hi,
>
> The test of subject starts with 36480 available cpb (if
> defaut cycles_per_bit = 16 is used) in our implementation. I
> think it's all right, because the sigcomp message is 160
> bytes long, thus available cpb = (1000 + 8 * 160) * 16 =
> 36480 < 66327 that the execution of the whole test costs. The
> result is decompression failure when trying to execute the 3rd SHA-1.
> I suggest that this should also be corrected in the next
> draft that it could be executed with default cpb.
>
> BR/Zacco
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Surtees, Abigail" <[email-masked]>
Date: Mon, 20 Jan 2003 13:36:31 -0000

Hi Zacco,

The original message is 0x932e ac71 = 10010011 00101110  10101100 01110001

As you say the first bits read are split as follows (10)(0100)(110010) which leaves 4 bits of the 2nd byte remaining.  At this point P changes to 1 which means that the remainder of the second byte (that is 1110) should be thrown away, according to section 8.2.  Then 1 bit is read from the 3rd byte but from the least significant bits first - that is 1010110(0) so the bit read is 0.  The next time 3 bits are read 1010(110)(0) and so on.

Best regards,

Abbie

>There input_bit_order = 1, i.e. P=1. Then it should input 1 
>bit of value 1 to the LSB of address 71, as a result of which 
>the OUTPUT will be 0001.
>
>Am I mistaken?
>
>BR/Zacco
>