headers
Bill Sommerfeld | 1 Feb 2011 01:14

Re: Ugh... xdr_{float,double} problems

On 01/31/11 15:34, Garrett D'Amore wrote:
> It sounds like all the main CPU targets support IEEE 754. The only
> reasonable (?) question IMO is S390. Roland? Neale?

There is an extensive discussion of floating point formats at:

http://www.quadibloc.com/comp/cp0201.htm

There is definitely a least one "IBM" floating point encoding out there.

Apollo's NCS RPC protocol (which is about as old as xdr) supported four 
different floating point format tags: IEEE, Vax, Cray, and IBM (mainframe).

My conclusion from the time I spent working in the group at apollo that 
did NCS is that you're generally better off avoiding the use of floating 
point numbers in wire protocols if at all humanly possible.  Lossless 
conversion between formats is often impossible, and a round-trip 
conversion between formats is likely to give you back a slightly 
different number.

Probably best to let sleeping dogs lie here..

						- Bill
Permalink | Reply | 1 comment |
headers
Owen Shepherd | 1 Feb 2011 01:22
Picon
Gravatar

Re: Ugh... xdr_{float,double} problems


On 1 Feb 2011, at 00:14, Bill Sommerfeld wrote:

> On 01/31/11 15:34, Garrett D'Amore wrote:
>> It sounds like all the main CPU targets support IEEE 754. The only
>> reasonable (?) question IMO is S390. Roland? Neale?
> 
> There is an extensive discussion of floating point formats at:
> 
> http://www.quadibloc.com/comp/cp0201.htm
> 
> There is definitely a least one "IBM" floating point encoding out there.
> 
> Apollo's NCS RPC protocol (which is about as old as xdr) supported four different floating point format
tags: IEEE, Vax, Cray, and IBM (mainframe).
> 
> My conclusion from the time I spent working in the group at apollo that did NCS is that you're generally
better off avoiding the use of floating point numbers in wire protocols if at all humanly possible. 
Lossless conversion between formats is often impossible, and a round-trip conversion between formats
is likely to give you back a slightly different number.
> 
> Probably best to let sleeping dogs lie here..
> 
> 						- Bill

S390 being as it is, it wouldn't surprise me if it has both IBM and 754 modes (And 754 mode is the way you're
supposed to do things in new software)

-- Owen Shepherd
http://www.owenshepherd.net/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Garrett D'Amore | 1 Feb 2011 01:30
Gravatar

Re: Ugh... xdr_{float,double} problems

I think that largely sums my feeling of floating point in general....

Bill Sommerfeld <sommerfeld <at> hamachi.org> wrote:

>On 01/31/11 15:34, Garrett D'Amore wrote:
>> It sounds like all the main CPU targets support IEEE 754. The only
>> reasonable (?) question IMO is S390. Roland? Neale?
>
>There is an extensive discussion of floating point formats at:
>
>http://www.quadibloc.com/comp/cp0201.htm
>
>There is definitely a least one "IBM" floating point encoding out there.
>
>Apollo's NCS RPC protocol (which is about as old as xdr) supported four 
>different floating point format tags: IEEE, Vax, Cray, and IBM (mainframe).
>
>My conclusion from the time I spent working in the group at apollo that 
>did NCS is that you're generally better off avoiding the use of floating 
>point numbers in wire protocols if at all humanly possible.  Lossless 
>conversion between formats is often impossible, and a round-trip 
>conversion between formats is likely to give you back a slightly 
>different number.
>
>Probably best to let sleeping dogs lie here..
>
>						- Bill
>
>_______________________________________________
>Developer mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gordon Ross | 1 Feb 2011 03:49
Picon
Gravatar

Re: Code review: Feature #677 - Allow adjustment of cache timeout in idmapd

Updated to include macros for the default timeouts.

http://cr.illumos.org/view/k47c4wv9/

Yes, these were apparently "pulled out of the air".  They're long enough in most
situations, but cause problems when an object has a lot of mapped IDs, as
described in the issue.

I think most customers will not need to adjust these, but for those who do,
this will be a very useful "knob" to have.

Gordon

On Sat, Jan 29, 2011 at 10:35 PM, Garrett D'Amore <garrett <at> nexenta.com> wrote:
> Looks pretty good to me.  I wonder where the 10 minutes and 1 hour came
> from though.  They feel like they should be placed as macros in a common
> header with other compile-time defaults (if any).
>
>        - Garrett
>
> On Sat, 2011-01-29 at 16:26 -0500, Gordon Ross wrote:
>> Please review the implementation of:
>>
>> Feature #677: Allow adjustment of cache timeout in idmapd
>> https://www.illumos.org/issues/677
>>
>> Here's the webrev:
>> http://cr.illumos.org/view/xjhhzxeh/
>>
>> Thanks,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Garrett D'Amore | 1 Feb 2011 04:16
Favicon

Re: Code review: Feature #677 - Allow adjustment of cache timeout in idmapd

Looks good to me.

     - Garrett

On 01/31/11 06:49 PM, Gordon Ross wrote:
> Updated to include macros for the default timeouts.
>
> http://cr.illumos.org/view/k47c4wv9/
>
> Yes, these were apparently "pulled out of the air".  They're long enough in most
> situations, but cause problems when an object has a lot of mapped IDs, as
> described in the issue.
>
> I think most customers will not need to adjust these, but for those who do,
> this will be a very useful "knob" to have.
>
> Gordon
>
> On Sat, Jan 29, 2011 at 10:35 PM, Garrett D'Amore<garrett <at> nexenta.com>  wrote:
>    
>> Looks pretty good to me.  I wonder where the 10 minutes and 1 hour came
>> from though.  They feel like they should be placed as macros in a common
>> header with other compile-time defaults (if any).
>>
>>         - Garrett
>>
>> On Sat, 2011-01-29 at 16:26 -0500, Gordon Ross wrote:
>>      
>>> Please review the implementation of:
>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joerg Schilling | 1 Feb 2011 10:30
Picon
Favicon

Re: Ugh... xdr_{float,double} problems

"Garrett D'Amore" <garrett <at> nexenta.com> wrote:

> It sounds like all the main CPU targets support IEEE 754.  The only 
> reasonable (?) question IMO is S390.  Roland?  Neale?

If I interpret the floating point code written by David M. Gay from AT&T 
correctly, then IBM and VAX are the two mayor deviations from IEEE.

But HPPA uses at least different parameters for long double than other IEEE 
architectures do.

Jörg

--

-- 
 EMail:joerg <at> schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js <at> cs.tu-berlin.de                (uni)  
       joerg.schilling <at> fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Permalink | Reply | 7 comments |
headers
Alexander Eremin | 1 Feb 2011 11:53
Picon
Gravatar

os-devel status

Hi,
anybody knows what's  with http://91.194.74.69:10000/ ?

Thanks,
Alexander
Permalink | Reply | 4 comments |
headers
Piotr Jasiukajtis | 1 Feb 2011 12:20
Picon

Re: os-devel status

Hi,

Ask Alasdair, he is managing that zone.

On Tue, Feb 1, 2011 at 11:53 AM, Alexander Eremin
<alexander.r.eremin <at> gmail.com> wrote:
> Hi,
> anybody knows what's  with http://91.194.74.69:10000/ ?
>
> Thanks,
> Alexander
>
>
> _______________________________________________
> Developer mailing list
> Developer <at> lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer
>

--

-- 
Piotr Jasiukajtis | estibi | SCA OS0072
http://estseg.blogspot.com

_______________________________________________
Developer mailing list
Developer <at> lists.illumos.org
http://lists.illumos.org/m/listinfo/developer
Permalink | Reply | 3 comments |
headers
Alasdair Lumsden | 1 Feb 2011 13:06
Picon
Gravatar

Re: os-devel status

Hi Piotr,

We have around 20-30 zones set up on a variety of physical hosts - can 
you confirm what this one is called?

Thanks,

Alasdair

On 02/ 1/11 11:20 AM, Piotr Jasiukajtis wrote:
> Hi,
>
> Ask Alasdair, he is managing that zone.
>
> On Tue, Feb 1, 2011 at 11:53 AM, Alexander Eremin
> <alexander.r.eremin <at> gmail.com>  wrote:
>> Hi,
>> anybody knows what's  with http://91.194.74.69:10000/ ?
>>
>> Thanks,
>> Alexander
>>
>>
>> _______________________________________________
>> Developer mailing list
>> Developer <at> lists.illumos.org
>> http://lists.illumos.org/m/listinfo/developer
>>
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alasdair Lumsden | 1 Feb 2011 13:59
Picon
Gravatar

Re: os-devel status

Hi Piotr,

The zone wasn't set to "autoboot=true", so when the physical host was 
rebooted, the zone didn't come back...

I've booted the zone up, and set it to autoboot in future.

Cheers,

Alasdair

On 02/ 1/11 11:20 AM, Piotr Jasiukajtis wrote:
> Hi,
>
> Ask Alasdair, he is managing that zone.
>
> On Tue, Feb 1, 2011 at 11:53 AM, Alexander Eremin
> <alexander.r.eremin <at> gmail.com>  wrote:
>> Hi,
>> anybody knows what's  with http://91.194.74.69:10000/ ?
>>
>> Thanks,
>> Alexander
>>
>>
>> _______________________________________________
>> Developer mailing list
>> Developer <at> lists.illumos.org
>> http://lists.illumos.org/m/listinfo/developer
>>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane