RSPAI?

 

Towards an RSPI for AI (UK) - alpha name RSPAI (short name "pai") 

The rspi was at one point going to be the BBC Nano (or model n)

but ended up as rspi because ... my reaction to the 100-200$ cost of the one laptop per child project, and to the limitations thereof...

An AI, like a computer, is a general purpose machine-

a purely physical tool analogy is a swiss army knife, but

software on computers is tools and die - tool and die

makers design, and build or repair tools. they have a bench

with lathes and saws and drills and hammers and screwdrivers and boxes full of bits...

A s/w toolbench is something like unix, with subsytems (network stack, file systems,

i/o in general (serial, display etc) plus SDK for development (vi, cc, add etc) and then

some handy pre-made tools (regex/grep, sort, awk, sed, etc) with source and documents available

so people could use them as design patterns (templates etc)

the RSPI prospered as it had 30 year pre-history 

(BBC Micro, Acorn, ARM, Broadcom system on chip) and ran 

Linux (descendent of bell labs et al) and had, 

on the system on chip a GPU (so it could use openGL rendering / gaming s/w) and 

wifi, and gpio (so it could connect to sensors and actuators and do robotics or similar

An RSPAI would also need to scale up - by being modular, and networks 

(c.f. wifi and gpio above - nowadays MCP or AI2AI or similar) and 

federated learning tools/platforms- the equivalent of s/w development environment

but with examples (e.g. start with some huggingface pieces) and flower.ai

A network, small and large...with a way to train (NN to FL)- in fact networking at on chip, in software, and between chips/systems...

It also needs some data (kind of AI equivalent to sensor input) - this doesn't have to be _on_ the RSPAI - it needs to be where you can get it (equivalent was that 

the Pi part of the Rasperry Pi name came from the original idea that like the BBC micro that booted into basic, the RSPI would boot into python. we discarded that early on and said kids must learn the Command Line (shell) but one simple example lesson (how to write Snakes in Python) would start with how to download and install python, and then... ... ...

It could run on an RSPI easily (esp. given cheapo GPU) but what is the core tool bench

for the Ai part of this RSPAI? is it just huggingface with pytorch tensorflow and all that gubbins, or is there a core that could be still general, but simpler to start off with and afford people with easy lessons 

(one class we ran with the RSPI had 11yr old schoolgirls withotu any teacher go from nothing to writing snakes in 1 hour from scratch) - what is the equiv to that, that lets you still also go all the way to writing a version of asteroids and control a bipedal lego robot?  

or genai including stable difussion video liks this:- https://youtu.be/kG8fmSW_5wM?si=hsbBdeCUtdshNyBM

A small neural net, a regression/stats library, some causal inference graph stuff? what what what?

And who is it for? policy makers, wannabe AGI gods, defense contractors, health and environment researchers, Jane Public who who who?

Answers on a postcard please...

Principles of Communications Week 9 to Dec 3rd/L16

Today we finished with systems design patterns, and a course summary.

For revision, maybe take a look at example supervision questions and past exam papers

Principles of Communications Week 8 to Nov 28th/L15

This week we covered the multiple time scales of traffic engineering and signaling, from packet time/scheduling to end-to-end/RTT latency admission control/call setup or else congestion control/queue management, to network wide provisioning and the interaction with pricing/utility, and consequences for possible accountability of end user/identity/payment systems...

Then we looked at a toolkit of system design patterns, with particular attention to communications systems, but with broad applicability in many domains/sectors/walks of life...

Principles of Communications Week 7 to Nov 21st/L13

This week we're covering firstly data centers (through the lens of q-jump and its clever "fan-in" trick), and secondly, optimisation of routes and rates. Both of these topics relate to practice, and theory of quite a few machine learning systems/platforms.

The mix of application platforms we see in the data center lecture are classic mapreduce (as represented by Apache Hadoop) and stream processing (as represented by Microsoft's Naiad)[2], as well as memcached (an in memory file store cache, widely used to reduce storage access latency and increase file throughput - e.g. for aforesaid platforms), as well as PTP (a more precise clock sysnch system than the widely used Network Time Protocol[1]). For an example of use of map reduce, consider Google's original pagerank in hadoop. For  the interested reader, this paper on timely data flow is perhaps useful background.

Optimisation is a very large topic in itself,  and underpins many of the ideas in machine learning when it comes to training - ideas like stochastic gradient descent (SGD) are seen in how assign traffic flows to routes, here. In contrast, the decentralised, implicit optimisation that a collection of TCP or "TCP friendly" flows use is more akin to federated learning, which is another whole topic in itself.

Why a log function? maybe see bernouilli on risk

Why proportional fairness? from social choice theory!

Are people prepared to pay more for more bandwidth? One famous Index Experiment says yes.

0. See Computer Systems Modeling for why the delay grows quickly as load approaches capacity.

1. see IB Distributed Systems for clock synch

2. see last year's Cloud Computing (II) module for a bit more about data centers&platforms.

Principles of Communications Week 6 to Nov 14th/L11

 This week we covered congestion control (with a brief mention of latest ideas of CUBIC and BBR) and scheduling (work conserving, max min fairness, and round robin with various tweaks, as well as queue management, with another appearance of "randomness" as a useful trick).

My analogy for the overall system that is TCP + IP is that it is like a bicycle, with a chain connecting two sets of gears - you can change gear at each end to change rate/speed, but the wheels slip (forwarding) and the chain is made of soggy bread (end to end rate).

IP forwarding+scheduling is like the bit where the rubber hits the road, and the foot on the pedal is like the sender, while the force backwards from friction, skidding and effort is the flow & congestion control.

Now loosely couple the chains of 10 billion bikes and riders and roads, and run them anything from 1 to a billion RPM...

and make the road surface out of jelly. and take a chain link out, or put on in every now and then (re-routing)...

and many of the bikes are penny farthings but some are jetskis (i.e. not everyone is running the same algorithm, either at IP level or end-to-end/TCP level).

Principles of Communications Week 5 to Nov 7th/L9

We covered mobile and telephony routing - key interesting idea is Dynamic Alternative Routing, a.k.a. sticky random routing, where the Gibbens paper covers the Max Flow analysis, plus this paper gives the statistical background on the triangle problem.

We then covered (essentially, revision of last years networks) flow and congestion control. There's an important link to control theory here which is covered in the Computer Systems Modeling module next term.

Principles of Communications Week 4 to Oct 31st/L7

This week, we'll finish up BGP, and cover multicast routing.

General lessons from BGP - information hiding can be harmful to decentralised algorithms. but information hiding may be a necessary dimension to some distributed systems due to business cases (commercial inconfidence/competitive data). 

Are there other ways to retain decentralised or federated operations but to retain also confidentiality? Perhaps using secure multiparty computations (not covered in this course!). There are a number of other federated services emerging in the world (applications like Mastodon and Matrix, and also, federated Machine Learning systems like flower) so this probably needs a good solution.

Multicast has a great future behind it - some neat thinking, but largely replaced by application layer content distribution networks (e.g. netflix, youtube, apple/microsoft software update distribution), and the move away from simultaneous mass consumption of video/audio. For more info on limitations of multicast, this paper is a good (quick) read. One of the key objections to multicast is that, like broadcast, it has great power (reach) but also great potential for harm - as a tool for launching denial of service attacks on many people at once, it could be rather handy, for bad people....source specific multicast was one way to limit this risk (so that ISPs could police those sources) - indeed, it would be fun if one could only have source-specific unicast so one would only have to receive packets from designated senders!

Finally, multicast IP has the same packet lost characteristics as normal IP, so you need to put an end-to-end reliable protocol on top of it for applications like software distribution (though perhaps not for video/audio etc). - this isn't as simple as using TCP (or QUIC) as the acknowledgement mecahsnisms would not work well for large groups (each data packet to a group of N recipients would cause a flood of N acks which woiuld likely overwhealm the sender or the senders network access). So you need new multicast transport protocols that manage reliability differently. This is another challenge for using IP multicast - although in some limited deployments (e.g. data centers) it might be a good fit for some applications.

In the analog world (e.g. radio, or audio) broadcast is obviously both good and bad - spark gap generators jam all the radios within considerable range, and white noise generators mess with everyone's hearing nearby...

Are application layer overlays a solution to other "in network" alleged enhancements? Possibly - for example, Cloudflare obviate the need tor always on IPv4 or IPv6 addresses - this also wasn't covered in this course, but might be of interest. Thir work is described here and other papers of theirs may be of current interest.

Principles of Communications Week 3 to Oct 24th/L5

This week, we'll start on BGP/Policy Routing, getting up to traffic engineering, including the amusingly named "hot and cold potato". Next week we will wrap up BGP covering semantics & performance.

A great overview of BGP if you want an alternate source.