dick balaska <dic### [at] buckosoftcom> wrote:

> >> Heh. Nice node names. How many boxes are in the farm?
> > 10 (3 i7, 5 i5, 2 Ryzen 1700 - all SSD and 8-16GB RAM).
>
> Well I'm jealous of *that*. I have (1) i7 and (3) i5.
So. That's a farm!!
Did I mention I was a 'consultant' before retiring? == adequate pension + loads
of time.
> >>
> >> UDP huh? That's an interesting choice.
> >>
> >  UDP is reliable enough.
>
> Yeah, it's reliable enough but ... I guess you're using some python
> library to assemble the small packets into a big message (like the
> returned image).

Nope. It's pretty simple Python - no classes or Obscure Obfuscation. All done at
the POV frame level with a shared (SMB) folder. I call it
UDPov. UDPov Job manager sends text message to client(s) to render a batch(1) of
frames. UDPov client calls POVRay command line with .ini file name and
start/end frame number(s). Client then writes whole image back into shared
folder and polls for next. Folder fills up with the frames and eventually they
can be combined (ffmpeg).
Development seems to be changing the structure of POVRay so that maybe we can
distribute work at the tile level but that's not here yet. Currently frame level
works for me. And anyway it's not always clear whether work is more efficiently
done at either the frame or at the tile level, especially for longer runs of
frames.

> I did an early innernet video game. UDP is great until it breaks. Error
> tracing is difficult. (I always thought it was me until my TiVo also
> gave me the same useless "No route to host" message. It's the same lan,
> you stupid box.)

I'm really talking 1970's here :-)  Back then you built in recovery at the
application level as well as at the network level.  Stupid application IMHO.
(but yeah. UDP is 'fire & forget' so you need to remember and retry. Er, did I
mention the 70's?)
>
> --
> dik
> Rendered 920576 of 921600 pixels (99%)

Post a reply to this message