Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #30294

Re: RPC/RMI in heterogeneous environments

Show all headers | View raw

On 1/31/2021 11:50 PM, upsidedown@downunder.com wrote:
> On Sun, 31 Jan 2021 12:37:27 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
> 
>> On 1/29/2021 11:33 AM, upsidedown@downunder.com wrote:
>>> On Thu, 21 Jan 2021 18:38:27 -0700, Don Y
>>> <blockedofcourse@foo.invalid> wrote:
>>>
>>>> I postpone automatic type conversion to the *servant*, rather
>>>> than embedding it in the client-side stub.  My reasoning is
>>>> that this allows a wider window for the targeted node to change
>>>> *after* the RPC/RMI invocation and before it's actual servicing.
>>>
>>> You must be quite desperate (extreme data rate, flea power client,
>>> very small memory client)  for even considering functionality that
>>> naturally belongs to the client.
>>
>> It's "power" (resource) related only in that time = 1/"power"
> 
> Computing power (and hence power consumption) is often exchangeable
> with time. Thus the _energy_ consumption of a complex operation can be
> nearly constant. This can be an issue in truly flee power systems, in
> which you may have to find algorithms with less complexity to reduce
> total energy consumption,

By "power", I meant all resources, not just watts.  A device can consume
very little power (watts) but also be crippled or capable in what it can
do in any given amount of time.  E.g., I can perform fast multiplies without
a hardware multiply -- if I can trade memory for time.

[It's also possible to be a power HOG -- and STILL not be able to do much!]

>>> Any healthy clients can handle byte order, time zones, character sets
>>> and languages.
>>
>> Convert Q10.6 to double
> 
> Q10.6 is already in binary representation fitting into a 16 bit word
> or two bytes.  Just some shifting to do the hidden bit normalization
> and some exponent adjustment and you are done. Should be easy with
> even any 8 bit processor. Doing it with some primitive 4 bitters (e.g.
> (4004/4040) would require more swapping between internal registers.

It's not a question of how complex the operation is vs the capabilities
of the processor; an MC14500 can EVENTUALLY pull it off!  But, increasing
complexity (with a given set of "capabilities") adds to "conversion delay".

The issue is putting this conversion task in series with the routing of
the packet.

If you convert parameters on the client-side, then the time spent
converting them increases the time until the packet gets onto the
wire and, ultimately, to the target node.  (Note that you had to make
assumptions as to WHICH node would be targeted in order to know
which conversions would need to be made.)  But, while you are busy
converting, a concurrent process (possibly on another node) can
cause the targeted object to be relocated to a new node.

So, the work done preparing the parameters for the original node is now
wasted; a NEW set of conversions need to be applied to fit the requirements
of the NEW target node (because you've decided that these conversions need
to be done at the *client*!).  I.e., even though the wire is ready for your
packet, your packet is no longer ready for the wire!

By contrast, if you ship the parameters "as is" and rely on the far end
to perform any necessary conversions, then the time between the
client invoking the RMI and the time the packet is ready to be placed
on the wire is shortened.  This reduces the likelihood of an "object
moved" event rendering your conversions futile (though it still means
your packet has to be routed to a different location than from the
one initially assumed).

> Of course a decimal number with 10 integer digits and 6 fractional
> digits (either in BCD/ASCII/EBCDIC) requires much more work and
> scratchpad areas.

Imagine shipping a 4K page of audio samples (because that is far more
efficient than shipping individual samples!) in little endian form to
a server that wants them in big endian form.

Or, a TIFF to a server that wants a JPEG.

Or, an array of 1000 floats to a server that wants IEEE 754 doubles.

I.e., "power" is a relative term.

(Of course, there are practical limits to the sorts of conversions you
can expected to do in this process.  But, you should be able to design
a client or a service with reasonable implementation flexibility...
and "fixup" for equally reasonable expectations from their counterparts)

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-21 18:38 -0700
  Re: RPC/RMI in heterogeneous environments George Neuner <gneuner2@comcast.net> - 2021-01-25 01:58 -0500
    Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-26 00:06 -0700
      Re: RPC/RMI in heterogeneous environments George Neuner <gneuner2@comcast.net> - 2021-01-26 13:23 -0500
        Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-26 13:39 -0700
          Re: RPC/RMI in heterogeneous environments George Neuner <gneuner2@comcast.net> - 2021-01-28 21:08 -0500
            Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-31 11:44 -0700
              Re: RPC/RMI in heterogeneous environments George Neuner <gneuner2@comcast.net> - 2021-02-01 15:50 -0500
                Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-02-03 21:19 -0700
  Re: RPC/RMI in heterogeneous environments upsidedown@downunder.com - 2021-01-29 20:33 +0200
    Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-31 12:37 -0700
      Re: RPC/RMI in heterogeneous environments upsidedown@downunder.com - 2021-02-01 08:50 +0200
        Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-02-03 20:53 -0700
  Re: RPC/RMI in heterogeneous environments upsidedown@downunder.com - 2021-01-31 21:39 +0200
    Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-31 15:21 -0700

csiph-web