🚀 go-pugleaf

Gegroet,

In be.science Patrick Smout <sopa@skynet.be> wrote:
>>> Niet dat ik 'min-waardig' wil doen over dit soort werk; maar -uit
>>> IT-standpunt gezien- is dit 'low level' (dwz, dicht bij de hardware;
>>> niet 'low' van 'laag niveau').

>> De ironie van informatica. Dat het moeilijkere werk low level wordt
>> genoemd en de spielerei high level :)

> Wat ik hieraan nog wil toevoegen:
> Schijnbaar vinden velen ook steeds dat 'high level' software geregeld eens
> mag crashen (blue screens, etc, hoort er nu eenmaal bij - 't blijven nu
> eenmaal computers).
Met 'high level' IT bedoel ik eerder iets anders.

Om even in het gebied van 'industriele toepassingen' te blijven. Ik kan
me goed inbeelden dat je computer hebt die elk een machine besturen en
controleren; maar daarnaast heb je ook nog systemen nodig die het
_geheel_ beheren.
Die flexibel zijn voor als er machines bijkomen of weggaan; die desnoods
het wegvallen van een machine moeten compenseren door de opdracht te
wijzigen van andere machines.

Ik ga het even vergelijken met mijn vakgebied (datacom, routers).
In elke router zit een heel stuk firmware voor het geheel van de
router; plus dan nog eens heel wat microcode die de sturing van (bv.)
individuele kaarten.

Maar daarnaast heb je nog een aantal protocols die tussenkomen spelen
tussen de verschillende routers (bv. routing-protocols), maar ook die
'acteren' op een centrale database (bv. IP PIM rendez-point voor
IP-multicast).

De dan nog hogere stap is dat je systemen hebt die allerlei meetingen
doen op je netwerk (lijn-belasting, geheugen-gebruik, CPU-load, hit/miss
rates van cache-engines, beschikbaarheid van ISDN-kaarten en
modem-kaarten, round-trip-delay metingen, enz. enz.).

Doel is
- "visualisatie" van de informatie,
(Vooral voor het vergemakkelijken van het 'trouble shooting')

- "fault-management"
* (wat doen indien een kaart uitvalt)
* het 'mappen' van ��n soort 'technische informatie' (nummer van kaart
of PVC in een router) naar "administratieve informatie" (welke klant
hangt achter die lijn)
* het 'koppelen' van feiten (een lijn die gaat 'bouncen' kan leiden tot
allerlei routing-berichten die heen-en-weer vliegen, met dus bijkomende
traffiek en gevolgen voor de CPU-load van routers op heel je netwerk)
* 'na dit MOET dat gebeuren' (bv. na het neer-gaan van een lijn MOET
binnen de zoveel tijd de ISDN backup-lijn opkomen)

- statistieken, trend-analyse
(Vooral de managers zijn verzot op dit soort cijfers ! ;-) )

enz. enz.

Het probleem is meestal dat de informatie komt uit verschillende hoeken
(meestal allemaal in hun eigen formaat met enkel hun 'lokale' technische
informatie); en dat het een systeem moet zijn dat heel flexibel moet
zijn inzake het toevoegen, weghalen of wijzigen van netwerk-elementen;
maar dat de "totale database" altijd moet coherent gehouden worden. (en
DAT is blijkt net een van de moeilijkste taken te zijn!)


Zoals ik al zei, is dit veel meer een IT job waar het toch wel
"interessant" is om je hersenen in de juiste kronkels te krijgen over de
'algemene samenhang van informatie'.


> 'Low level' software wordt echter steeds verondersteld van altijd
> beschikbaar te zijn, 24h/24h. Daarom dat wij ook begrippen handteren zoals
> high-availability (sorry jongens, geen tijd om een database te
> reorganiseren, de wereld draait nu ��nmaal verder).
Hmm. Geloof me of niet; maar de firmware van routers is soms ook niet
wat het zou moeten zijn.

Meestal, indien je een firmware-versie gebruiken met de 'features' die
iedereen gebruikt (bv. enkel standaard IP) dan heb je heel zelden
problemen; maar als je begint met 'niet zo standaard' zaken
(IP-multicasting in combinatie met MPLS of IP-NAT, IPv6, MPLS,
verschillende routing-protocols die op elkaar moeten inwerken,
niet-zoveel gebruikte interface-kaarten, enz. enz) dan durft het wel
eens serieus in de mist gaan!

Cisco-routers zijn m.i. een heel mooi staaltje techniek; bv. inzake
'distributed processing' (meeste individuele lijn-kaarten hebben een
eigen processor en draaien onafhankelijk hun eigen software; en hebben
daarnaast nog een aantal 'custom' chips die ook een stuk van de
processing overnemen; of DSP-processoren -bv. voor modem of
Voice-over-IP) ook met hun eigen microcode en specifieke 'interactie'
met het hoofdsysteem).

Dat is natuurlijk noodzakelijk voor de throughput van het systeem (hoe
kun je anders de zoveel gigabit/seconde throuput halen); maar "soms" leidt
dat wel tot stabiliteits-problemen.
In elk geval. Hoedje af voor de mensen die die dingen moeten ontwerpen!


> O ja bijna vegeten, pentium 166 met 32 Mbyte RAM, ongekende luxe, geloof me.
> Ik dacht meer aan zoiets van 80188/80386 op 40 Mhz, 256K Flash, 128K ram,
> met embedded IP stack en PPP, PAP/CHAP, SMTP en HTTP.
Ik dacht dat ondertussen de meeste 'embedded controllers' toch wel al
powerPC of MIPS-achtige dingen waren met ��n of ander variant van een
real-time OS op; en toch een redelijk aan megahertzen achter hun kiezen?


> Tja, misschien daarom dat zo ons wel eens smalend 'bitneukers' noemen, maar
> dat beschouw ik meer als een compliment!
Wel, ik heb ooit nog met een logic-analyser de seriele uitgang van een
8751 moeten monitoren om een foutje te vinden in een stuk programma van
me (en 300 baud, gesampled op 1 Kz heeft wel geen vast aantal samples
per 'bit'). Na een kwartiertje was ik echt 'tureluur'.
DAT was dan echt 'bitneuken' op het laagste niveau! (Dat ik toch ooit
gedaan heb). ;-)


> Patrick Smout
Cheerio! Kr. Bonne.