[Nottingham] Eager Queues and GNU Hurd.

[Martin]

Jason Cozens wrote:
> On Sat, 2007-01-20 at 17:19 +0000, Martin wrote:
>> Jason Cozens wrote:
> 
>>> Solution
>>> ========
>>>
>>> A protocol that uses UDP is defined called the Eager Queue Protocol.
>>> This protocol works in a similar way to a job exchange. Workers enter
>> [...]
>>> The protocol uses UDP a well established and widely available protocol.
>>> The main benefit of the protocol will be to move away from a centralised
>>  more powerful and expensive processors.
>>> From initial investigations it look as though EQP will be able to
>>> combine with the translators of GNU Hurd.
>> YEAH!!
>>
>> My first thought is that there is an awful lot of _broadcasting_ going
>> on with that lot that could then quickly swamp a network as you add more
[---]
> There is a lot of _broadcasting_ going on but this is intentional.
> 
> Firstly the idea would be to have scheduling on a private network
> reserved exclusively for scheduling. To test this I'd like to get
> some computers, put in an extra network card and write the scheduling
> software.

OK, so all the more reason for a LAN party soon! There's also such as
Josh whom could perhaps test out an entire lab of PCs...?

Or would a group on NTL or some other ISP work well enough?

Checking diary and events: LAN Party Sunday 18th Feb. Who's interested?

(I'll have a few bits'n'pieces to show off by then also.)


> The channel is very noisy so that processors can join quickly.
[---]
> Although there are a lot of broadcasts there won't be too many
> collisions. The purpose of continually broadcasting the state of
> the scheduling is that every scheduling processor knows which
> processor is expected to broadcast next. This not only avoids
> collisions but helps to isolate faulty processors.

OK, a sort of round-robin roll-call.

However, there is still the overhead of all processors listening in on
all the traffic. Better if they could ignore the broadcasts until they
need to interact again? Use a directed packet to the next processor whom
should broadcast?

If connected to a switch, collisions shouldn't be a problem unless you
overload the forwarding buffers in the switch.


[---]
> I'd like to give a talk on this. It would be best if it was towards the
> end of Feb or beginning of March as I'd like to flesh the ideas out a
> bit more and maybe get some code written.
> 
> Cheers,
> Jason.

I'm certainly very interested in this.

We have next:
Beeston Beers;
Foodie Social;
LAN Party?;
LaTeX pt2;
Foodie Social;
GStreamer or Eager Queues.

Or we add an extra talk into March to make up for the short February?


> PS: Does anyone know a good reference on C and UDP?
> I've only used UDP with C# so far and don't think a managed environment
> is what I need here.

Anyone?


Cheers,
Martin

-- 
----------------
Martin Lomas
martin at ml1.co.uk
----------------