1. Телефон (Java/Symbian)
Трябва ви какъвто и да е телефон с поддръжка на MIDP-2.0 и CLDC-1.1. Телефона ви трябва да има поне 500KB оперативана памет и доста повече за карти. В момента карта на регион с размери 3 на 3 км (Пловдив) с приближение от 11 до 18 заема 16МВ на телефона ми. Карта на цяла България с приближение от 8 до 13 заема 55МВ.

2. GPS приемник
Всякакъв приемник, който се свързва по Bluetooth е подходящ. Доста разпространен и евтин модел е Holux M-1000. Нов струва около 80лв, а моя го взех от Ebay за 20. Малък е (като кибритена кутия), събира се във всякакви джобове. Батерията му държи към 10+ часа (из нета пишат за 20+ часа) и приемането му е добро, дори когато сте в кола, влак и т.н. MTK чипсет. В комплекта има зарядно за кола и USB кабел, който може да се използва пак само за зареждане на батерията. Батерията е Nokia-съвместима, така че за под 10 лв може да си вземете втора от руския пазар. Скоростта не се дава много коректно - разлика от до 5 km/h е допустима във кола. Във влак, където няма неравномерни ускорения като че ли е малко по-точно. За пешеходци текущата скорост варира между 0-10 km/h и не може да се гледа. Но ако правите трак накрая може да видите средна аритметична скорост.
3. Софтуер
- MapNav - http://mapnav.spb.ru/site/download.php?list.3 - изисква регистрация (става бързо и безплатно) - това се инсталира на телефона ви.
- mobile map creator - http://mapnav.spb.ru/site/download.php?list.4 - също - това се инсталира на компютъра ви (дори работи с Wine)
- Ozi Explorer - http://www.oziexplorer.com/ - програмата струва $95, но който държи да си пиратства - има я из торентите. Програмата служи за калибриране на растерни карти и не е необходима, ако не мислите да правите това. Също се инсталира на компютъра (и пак работи с Wine)

MapNav
1. Features
- език на интерфейса - руски, английски, български и др.
- 18 нива на приближение, като на най-високото разделителната способност е около метър на пиксел.
- правене на трак, като слага точките по изминато разстояние, минало време или при промяна на посоката. Без проблеми прави трекове с 3000+ точки, като има опция за олекотяване да показва само последните 100 точки. Дава профили на на пътя по височина и по скорост. Траковете могат да се експортват/импортват в GPX, KML или Ozi формат.
- компас, който показва посоките релативно на посоката на движение.
- водене по маршрут или контролни точки - waypoints.
- заключване на клавиатурата
- затъмняване на екрана - върши добра работа за пестене на батерия
- смяна на картите по време на работа.
- използване на ваши карти (в MNO формат - правят се с mobile map creator, виж по-долу) или онлайн такива (ако имате мобилен интернет).
- спортен режим на засичане на обиколки - не съм го пробвал.
- в основния екран се показват картата, текущата позиция на нея, координати, скорост, надморска височина и др.
- слагане на измерителна скала върху картата
- ръчно задаване на път
- слагане на белязки, които после може да ползвате за waypoints или Points Of Interest
- импорт и експорт на трaкове, waypoints, маршрути и др. Поддържа GPX формат и няколко други.
- настройки за всичко, което можете да се сетите.
- правене на скрийншот
- описание на mapnav на английски - http://mapnav.spb.ru/site/page.php?15 и на руски - http://mapnav.spb.ru/site/page.php?10

Карти
1. Калибриране с Ozi
1.1. В Ozi Explorer (бих пуснал снимки, ако притежавах програмата)
File -> Load and Calibrate Map Image
Избиране на растерната карта.
Избиране Point 1 -> клик в единия ъгъл на картата; в дясно на Degrees & mins се попълват координатите на точката
Избиране Point 2 -> клик в друг ъгъл на картата; попълват се новите координати
Point 3 - по същия начин
Save -> избирате къде да бъде запазен .MAP файла - това е информацията за калибровката на картата и ще се използва в следващата стъпка.
1.2. В Mobile Map Creator
Горе трябва да е избран таба Convertor.
Кликате на първата иконка (текста на нея е нещо като Select map to convert).

В нея зареждате .MAP файла, който имате от Ozi-то. Внимание: ако сте свалили МАР файл от нета, отворете го и оправете пътя до растерното изображение да сочи правилно към изображението което имате (C:\Ozi\superdupermap.map при един ще е D:\Documents And Settings\usr\My Documents\plovdiv.map при друг). Пътя до изображението е на третия ред във МАР файла, който се отваря като текстов с Notepad. Ако сам сте си направил МАР файла, няма нужда от подобна манипулация.
Зареждате МАР файла и избирате къде да запазите крайните карти. Ще получите два файла с разширения MNM и MNO. Този с разширението MNМ се използва като вътрешна карта, която може да вградите в самата програма MapNav, но авторите й препоръчват да не се прави така. Използвайте MNO файла и си работете с външна карта.
2. Сваляне на уеб карти (Virtual Earth)
Горе трябва да е избран таба Map.

Първия плъзгач е за zoom level-a на избраната карта. Картата източник се избира от падащото меню. В момента са налични VirtualEarth, Google, OSM и др. Могат да се добавят още с директно редактиране на maps.ini. В прозореца с картата можете да влачите докато намерите областта, която ви интересува. Кликате на Set to map и избирате с мишката района. Трябва да се появи с инвертиран цвят. Под този бутон се намира Map Zoom - стойността вътре показва какво приближение ще имате в получената карта накрая. С бутона "+" добавяте селекцията в компилацията. Внимание: изберете всичките приближения, които искате да имате после в MapNav-a! Примерно ако искате да имате от ниво 11 до ниво 13, задавате ниво 11, кликате "+", задавате ниво 12, кликате "+", задавате ниво 13, кликате "+".

Цифрите ви показват колко плочки (tiles) ще се свалят от нета. Това е и горе долу показател за размера на картата накрая. Когато сте доволни от селекцията, кликате Compile Map и избирате къде да се запазят двете карти MNO и MNM.

Инструменти за визуализиране на трекове
1. Онлайн

http://www.everytrail.com/

- може да ъплоудвате тракове в GPX формат - public (всеки може да гледа трака) и private (само вие можете да го гледате) режими
- дава профил на терена по скорост и по височина
- ъплоудване на снимки и геотагване
- пътепис
- търсене и браузване на тракове
2. Десктоп
- Google Earth - да се провери какво става там. Вероятно трябва да работи с KML.

• върви на Windows, Linux и Mac OS
• пуска се с 1 клик и дава бърз резултат
• резултатите са разделени на няколко секции: целочислени операции, операции с плаваща запетая, памет и цялостен резултат. Точките са линейно пропорционални - ако компютър А има 500 точки, компютър Б има 1000 точки, а компютър В има 2000 точки, то Б е два пъти по-бърз от А, В е два пъти по-бърз от Б и четири пъти по-бърз от А.
• бенчмаркът е написан така че да се възползва от произволен брой ядра на процесора, с или без Hyperthreading
• може да изпратите резултата си до онлайн базата с данни, която и без това е доста богата

Естествено не трябва да се забравя че това е обикновен тъп синтетичен бенчмарк и поведението на тестваните машини в реални условия може да е друго.
Тествах четири машини тук и ето резултатите:

1) Celeron 500MHz (66MHz FSB), i440zx, 128+64MB PC100 SDRAM - overall performance 230
2) Pentium Dual Core T2390 (1.8Ghz, 533Mhz FSB), GS965, 2*1GB DDR2 667MHz - overall performance 2030
3) Pentium 4 Prescott (3GHz, 800MHz FSB), i945, 512+512+1 DDR2 667MHz - overall performance 1740
4) C2D T2400 (1.8Ghz, 667Mhz FSB), GM945, 2GB DDR2 667Mhz - overall performance 2135 (governor - ondemand)

Като се прибера в Пловдив ще го пусна и на виртуалната машина (Ъпдейт: излезе много близко до реалния пеформанс - около 1500)

The IBM AP-101 computers originally had about 424 kilobytes of magnetic core memory each. The CPU could process about 400,000 instructions per second. They have no hard disk drive, and load software from magnetic tape cartridges.

Процесора има 16 броя 32-битови регистри, а наборът му от инструкции се състои от 154 инструкции, които могат да се променят чрез смяна на микрокода. Интересното е че целия процесор е в TTL изпълнение (!!!) и има скромните размери от 15/25/45 см. Тежи 25 кг.
През 1990 г. компютърът е бил ъпгрейднат с новата версия - AP-101S. Този звяр е имал около 1МВ памет и три пъти по-бърз процесор (изпълнявал е около 1.2 млн инструкции в секунда). Паметта вече не използва магнитно ядро, а CMOS технология с батерийно захранване. Това са данните за ъпгрейднатите части:

The main memory of each GPC (General Purpose Computer) is non-volatile (the software is retained when power is interrupted). The memory capacity of each CPU is 81,920 words, and the memory capacity of each IOP is 24,576 words; thus, the CPU and IOP constitute a total of 106,496 words.

Сто хиляди думи програма. Софтуера на совалката може да се събере в паметта на микроконтролера, който ползвам за дипломната си работа.
В совалката е имало шест компютъра с общо предназначение (GPC-та). Пет от тях са правили едни и същи изчисления. Резултатите се сравняват и ако някой от компютрите даде различен резултат, останалите го приемат за грешка и го изключват от системата. На шестият компютър върви същата програма, но написана от съвсем независим източник. Той е последната възможност на астронавтите ако всички други компютри откажат.
Всеки от AP-101 компютрите използва по 600 вата мощност.

Интересни са прогнозите през годините за това колко памет ще иде за програмата на совалката.

Most estimates in the 1969 to 1971 period ranged around 28K words. Rockwell International settled on 32K in its bid and won the contract partially because of that estimate. NASA, trying to save itself from later difficulties, bought 64K of memory for each computer, hoping that doubling the estimate would be enough (despite memory increases in previous programs of several hundred percent). Unfortunately, the
software grew to over 700K, requiring not only more computer memory, but the addition of mass memory units to hold programs that would not fit into the extended core. Parten said after this, "I don't know how
you ensure proper memory size ahead of time, unless you're incredibly lucky".

Програмите за излитане, за поддържане на орбита и за обратно навлизане в атмосферата са се съхранявали на отделни ленти, които астронавтите са зареждали в съответните случаи. След ъпгрейда с AP-101S, вече всички програми е можело да бъдат съхранявани в главната памет.
Интересен е бил бъгът в софтуера, който е рестартирал компютрите при всяка смяна на годината от 31 декември към 1 януари. За това совалките не са правели полети, които включват тези дати. Този бъг е бил оправен чак през 2003 г.
Компютрите са можели да бъдат препрограмирани в полет, ако се появи критична ситуация:

The memory can be altered in flight. The ground can uplink bursts of 64 16-bit halfwords at a time, which can replace data already in the specified addresses. The crew can also change up to six 32-bit words simultaneously by using their displays and keyboards. However, those changes must be hand keyed in hexadecimal.

Представяте ли си как астронавта за три секунди набира сто инструкции по машинни думи

Понеже видео обработката по онова време е била трудоемка работа, цял отделен компютър е бил посветен на обслужването на дисплеите, където се извеждала информацията от останалите компютри.

Displays placed on the CRTs are controlled by a special-purpose computer with a 16-bit word size and 8K of memory. This computer provides display control and can create circles, lines, intensity
changes (highlighting), and flashing messages.

Интересни неща могат да се намерят за компютрите в космоса
По материали от Wikipedia и изходящите й връзки.

• Device Drivers --->[*] Network device support ---> PPP (point-to-point protocol) support
• Device Drivers --->[*] Network device support ---> PPP support for async serial ports

Ако решите да ги компилирате като модули, първия модул ще се казва ppp_generic, а втория ppp_async. Трябват ви и двете неща, иначе ще получавате странни грешки от рода на:

The PPP daemon has died: Fatal pppd error (exit code = 1)
1 An immediately fatal error of some kind occurred, such as an
essential system call failing, or running out of virtual mem-
ory.

Wvdial
Хубавото на Wvdial е че само си открива поддържаните настройки от модема и само си създава конфигурационен файл. Освен това не е нужно да се мъчите с /etc/ppp/* скриптове и настройки и даже не е нужно да сте прочели и ред от pppd man-страницата
Създаване на конфигурационен файл:

# wvdialconf
Editing `/etc/wvdial.conf'.

Scanning your serial ports for a modem.

WvModem<*1>: Cannot set information for serial port.
ttyS0<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud
ttyS0<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 115200 baud
ttyS0<*1>: ATQ0 V1 E1 -- and failed too at 115200, giving up.
WvModem<*1>: Cannot set information for serial port.
ttyS1<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud
ttyS1<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 115200 baud
ttyS1<*1>: ATQ0 V1 E1 -- and failed too at 115200, giving up.
Modem Port Scan<*1>: S2 S3
WvModem<*1>: Cannot get information for serial port.
ttyACM0<*1>: ATQ0 V1 E1 -- OK
ttyACM0<*1>: ATQ0 V1 E1 Z -- OK
ttyACM0<*1>: ATQ0 V1 E1 S0=0 -- OK
ttyACM0<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK
ttyACM0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK
ttyACM0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK
ttyACM0<*1>: Modem Identifier: ATI -- Sony Ericsson K810
ttyACM0<*1>: Speed 4800: AT -- OK
ttyACM0<*1>: Speed 9600: AT -- OK
ttyACM0<*1>: Speed 19200: AT -- OK
ttyACM0<*1>: Speed 38400: AT -- OK
ttyACM0<*1>: Speed 57600: AT -- OK
ttyACM0<*1>: Speed 115200: AT -- OK
ttyACM0<*1>: Speed 230400: AT -- OK
ttyACM0<*1>: Speed 460800: AT -- OK
ttyACM0<*1>: Max speed is 460800; that should be safe.
ttyACM0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK
WvModem<*1>: Cannot get information for serial port.
ttyACM1<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud
ttyACM1<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 115200 baud
ttyACM1<*1>: ATQ0 V1 E1 -- and failed too at 115200, giving up.

Found an USB modem on /dev/ttyACM0.

Отваряме /etc/wvdial.conf и редактираме редовете Phone, Username, Password. Добавяме и ред Init3. Това е крайното състояние при мен (за МТЕЛ) :

[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = AT+CGDCONT=1,"IP","inet-gprs.mtel.bg"
Modem Type = USB Modem
ISDN = 0
Phone = *99#
Modem = /dev/ttyACM0
Username = dada
Password = dada
Baud = 460800

По принцип интернета на МТЕЛ се използва с каквито и да е Username и Password, но wvdial не ви позволява да оставяте тези полета празни. Из нета на разни места пишат че може и да се сложи следния ред:
Stupid Mode = 1
ако wvdial не може да си комуникира добре с модема ви. За k800i нямаше нужда.
Connect
Стартирането на pppd, което става автоматично от wvdial изисква отново да сте root.

# wvdial
--> WvDial: Internet dialer version 1.60
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: ATZ
ATZ
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
OK
--> Sending: AT+CGDCONT=1,"IP","inet-gprs.mtel.bg"
AT+CGDCONT=1,"IP","inet-gprs.mtel.bg"
OK
--> Modem initialized.
--> Sending: ATDT*99***1#
--> Waiting for carrier.
ATDT*99***1#
CONNECT
~[7f]}#@!}!}!} }9}#}%B#}%}(}"}'}"}"}&} } } } }%}&VKD}1[7f])~
--> Carrier detected. Starting PPP immediately.
--> Starting pppd at Sun Feb 22 19:48:09 2009
--> Pid of pppd: 26823
--> Using interface ppp0
--> pppd: 8[07][08]X¢[07][08][07][08]
--> pppd: 8[07][08]X¢[07][08][07][08]
--> pppd: 8[07][08]X¢[07][08][07][08]
--> pppd: 8[07][08]X¢[07][08][07][08]
--> pppd: 8[07][08]X¢[07][08][07][08]
--> pppd: 8[07][08]X¢[07][08][07][08]
--> pppd: 8[07][08]X¢[07][08][07][08]
--> pppd: 8[07][08]X¢[07][08][07][08]
--> local IP address 10.161.47.249
--> pppd: 8[07][08]X¢[07][08][07][08]
--> remote IP address 10.64.64.64
--> pppd: 8[07][08]X¢[07][08][07][08]
--> primary DNS address 213.226.7.34
--> pppd: 8[07][08]X¢[07][08][07][08]
--> secondary DNS address 213.226.7.35
--> pppd: 8[07][08]X¢[07][08][07][08]
^CCaught signal 2: Attempting to exit gracefully...
--> Terminating on signal 15
--> pppd: 8[07][08]X¢[07][08][07][08]
--> Connect time 1.5 minutes.
--> pppd: 8[07][08]X¢[07][08][07][08]
--> pppd: 8[07][08]X¢[07][08][07][08]
--> pppd: 8[07][08]X¢[07][08][07][08]
--> Disconnecting at Sun Feb 22 19:49:38 2009

CTRL+C спира връзката.
Има няколко важни неща, които трябва да се видят тук. Това че сте свързан към GPRS access point при оператора ви все още не означава че компютъра ви може да ползва интернет. Трябва да се добави default route, със следния gateway:
--> remote IP address 10.64.64.64
Съответно:
# route add default gw 10.64.64.64
Ако преди това сте бил свързан към друг доставчик явно ще трябва да махнете default gw, който ви е от него.
При спирането на връзката може да забележите следния ред, който показва за колко време сте били connected:
--> Connect time 1.5 minutes.
Други статистики може да видите от ifconfig ppp0:

ppp0 Link encap:Point-to-Point Protocol
inet addr:10.161.47.249 P-t-P:10.64.64.64 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:64 errors:0 dropped:0 overruns:0 frame:0
TX packets:317 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:7125 (6.9 KiB) TX bytes:53884 (52.6 KiB)

Конкретно това което ви интересува е RX и TX bytes, защото те струват пари. Не съм сигурен дали оператора отчита трафика по същия начин, за това не бих приел тези цифри много твърдо.

И финалния най-важен въпрос: колко бърз интернет можете да си пуснете - при мен стигна до четвърт мегабит:

wget http://mirrors.unixsol.org/linuxpackages//Slackware-12.0/ken/google-earth-4.2.205-i486-1kjz.tgz
--19:54:57-- http://mirrors.unixsol.org/linuxpackages//Slackware-12.0/ken/google-earth-4.2.205-i486-1kjz.tgz
=> `google-earth-4.2.205-i486-1kjz.tgz'
Resolving mirrors.unixsol.org... 193.110.159.35
Connecting to mirrors.unixsol.org|193.110.159.35|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 22,863,884 (22M) [application/x-tar]

1% [> ] 442,690 37.82K/s ETA 10:23

Това зависи от мрежата, която ви покрива. Максималните скорости са съответно:

• CSD (WAP dial-up) - 9.6 Kbps
• GPRS - 90 Kbps
• EDGE - 236 Kbps
• UMTS - 384 Kbps
• HSDPA - 14.4 Mbps downlink

Внимание: всичко различно от WAP CSD може сериозно да ви бръкне в сметката! MTEL дават 1MB трафик за 2.50 лв. Тарифата за WAP е 11 ст. на минута. Горното howto е писано за всичко от GPRS нагоре. За чист WAP ще експериментирам и тези дни вероятно ще пусна Part 3 на това howto.

Update: Операторката от телефон 1010 ми съобщи че MTEL от една година насам не предлагат CSD достъп, а само GPRS.

Статията може да е скучна за доста хора, така че който го интересува да чете навътре

Има различни реализации на алгоритми за подобряване Качеството на услугата (QoS), които са известни още под името "планировчици". Повечето от тях използват клас-базирани опашки (CBQ) - трафика се разделя по класове. Всеки клас има лимит (част от общия лимит на връзката), който не може да се надвиши от сесиите, които попадат в класа. Различни планировчици са: RED, ECN, CBQ, HTB, WFQ, WRR, HFSC... "HFSC" означава "честна йерархична крива на услугата". Целта на алгоритъма е да гарантира адаптивно и гъвкаво изменение на трафика в реално време; плавно споделяне между йерархчно разположените класове. Какви са ползите от подобен тип алгоритъм:

• може да се направи филтър, който вкарва ACK пакетите в клас с по-висок приоритет. Така трансферите ще преминават с нормална скорост, дори и при натоварена връзка.
• може да се контролира забавянето на пакетите (latency) както и скоростта им на преминаване (bandwidth)
• може да се задават точни параметри на пиковите трансфери (burst), които са с малка продължителност, но използват връзката на максимум. Тези параметри включват големина на пика и плавното му намаляване след максимално определената продължителност. По този начин кратки трансфери ще преминават по-бързо (каквито са HTTP заявки и отговорите), докато големите трансфери ще се ограничават и няма да заемат целия капацитет на връзката.
• гарантиране поведение на услугата във всички крайни класове
• честно разпределение на свободния трафик към крайните класове

Планирането чрез HFSC се основава на два принципа: предаване на трафик в реално време, което гарантира сервизната крива на крайните класове и споделяне между класовете, което се стреми да разпредели свободните ресурси. Политиката на планировчика е да активира първия принцип, когато има опастност крайните класове да не могат да получат минималния им гарантиран ресурс. През останалото време е активиран втория критерий. За да се разбере принципа на действие на HFSC трябва да се вникне в няколко модела на управление на качеството на услугата.

Модел на управление качеството на услугата чрез сервизна крива

Сервизна крива - Service curve - това е графика на преминалите данни за единица време.

Кривата има три параметъра:

• m1 - наклон на първия сегмент
• m2 - наклон на втория сегмент
• d- пресечна точка на двата сегмента по оста Х

Според подобра на параметрите могат да се направят криви с различен наклон, вдлъбнати или изпъкнали. Вдлъбнатата крива работи добре с кратки пикове, които не стигат до максимално разрешеното време - точката d. Тази крива пропуска началото на трансфера и го ограничава ако се окаже че той не е пик, а изисква голям ресурс по цялата си дължина. Изпъкналата крива потиска първоначалния трафик и дава приоритет на връзки, които преминат точката d. Естествено може да се постигне и линейна сервизна крива, когато двата наклона са еднакви: m1 = m2.
Настройването на сервизна крива дава основен инструмент за управление качеството на услугата. Все пак това не стига за честно разпределяне на свободните ресурси между крайните класове.

Модел на виртуалното време

Всеки от класовете в йерархията има параметър vt - виртуално време, който представлява броя обслужени байтове за единица време. ВТ е въведено за първи път в PFQ (Packet Fair Queueing) алгоритъма и целта на параметъра е да синхронизира дъщерните класове в йерархията в принципа за споделяне на връзката. Когато стане възможно да се изпрати пакет се претърсва всеки от класовете в йерархията за най-малка стойност на виртуалното време. Крайният клас, който съвпадне с това изискване изпраща пакет и виртуалното време на този и на всеки друг клас нагоре по йерархията (до коренния клас) се увеличава. Винаги когато един клас изпраща пакет виртуалното му време се увеличава.

Модел на управление качеството на услугата чрез разпределяне и честна сервизна крива

Не само крайните класове, а всеки клас в йерархията има собствена сервизна крива. Целта е едновременно да се задоволят сервизните криви на крайните класове и излишъка от ресурс да бъде честно разпределен. HFSC използва този модел.
Всеки краен клас има следните три параметъра:

• d - максимално допустимото време на престой за пакет на края на опашката на класа
• e - желателното време за престой
• v - виртуалното време, свързано с класа

Класовете, които не са крайни имат само v параметър. Максималните времена на престой се изчисляват така че, сервизната крива е гарантирана когато всички пакети от дадена сесия имат време по-малко от d. Времето e се използва за избор на кой от двата планиращи принципа ще се активира за следващия пакет. Ако текущия пакет е престоял по-малко от времето e - продължил е нататък по връзката за кракто време, алгоритъма преценява има излишък от ресурс и се стреми да го разпредели. Ако текущия пакет е престоял повече от желателното време e, това е сигнал за потенциално претоварване и алгоритъма активира критерия за минимален гарантиран ресурс.

Имплементация в Linux

За контролиране качеството на услугата в Linux може да се използва инструмента tc, който е част от комплекта iproute2. Този документ няма да описва действието на tc и се предполага че читателите са запознати с него. Първата стъпка е да се инсталира обслужваща дисциплина (qdisc) към мрежовия интерфейс. Може да се добави и опция за използване на клас по подразбиране, в който ще попадне некласифицирания трафик. Общ синтаксис:
tc qdisc add dev $dev root handle $ID: hfsc [default $classID]
Пример:
tc qdisc add dev eth0 root handle 1: hfsc default 10
Добавяне на класове и изграждане на йерархия, чрез връзката parrent <-> classid.
Общ синтаксис:
tc add class dev $dev parent parentID classid $ID hfsc [ [ rt SC ] [ ls SC ] | [ sc SC ] ] [ ul SC ]
SC := [ umax bytes dmax ms ] rate BPS
Крайните класове могат да имат параметър за гарантиран ресурс в реално време (rt) както и параметър за сервизната крива, когато е активиран принципа за споделяне (ls). Вътрешните класове имат само параметъра ls, който е свързан с виртуалното време. Параметъра ul показва максимално заделения трафик, който може да попадне в класа. Параметрите rt и ls могат да бъдат изпуснати и вместо тях да се ползва описание на сервизната крива (sc). Тя се описва чрез:

• rate - скорост на предаване - височина на втория сегмент на кривата
• dmax - максимално закъснение - времето където се съединяват двата сегмента
• umax - скорост на предаване - височина на първия сегмент на кривата

Примерна йерархия от класове

tc class add dev eth0 parent 1: classid 1:1 hfsc sc rate 1000kbit ul rate 1000kbit
tc class add dev eth0 parent 1:1 classid 1:10 hfsc sc rate 500kbit ul rate 1000kbit
tc class add dev eth0 parent 1:1 classid 1:20 hfsc sc rate 500kbit ul rate 1000kbit
tc class add dev eth0 parent 1:10 classid 1:11 hfsc sc umax 1500b dmax 53ms rate 400kbit ul rate 1000kbit
tc class add dev eth0 parent 1:10 classid 1:12 hfsc sc umax 1500b dmax 30ms rate 100kbit ul rate 1000kbit
Другата част, която не засяга HFSC планировчика и няма да бъде разглеждана е създаване на филтър, който да класифицира трафика.
Пример:
tc filter add dev eth0 protocol ip parent 1: u32 match ip sport 80 0xffff classid 1:10

Имплементация в *BSD

HFSC за първи път бива вградено в open source решение за контрол качеството на услугата - това е ALTQ. ALTQ се използва в комбинация с пакетния филтър pf. Този документ няма за цел да описва пакетния филтър, така че ще се концентрираме върху HFSC. Използват се следните параметри:

• bandwidth - капацитета на връзката за даден клас. Стойността за bandwidth на дъщерните класове винаги трябва да е по-малка от bandwidth на родителския клас. Стойността за подразбиране на bandwidth е 100% от възможното за родителския клас. Стойността може да се задава в проценти, mbit, kbit...
• priority - приоритет на обслужване на класовете. Тази директива е прост начин за определяне на кои класове ще могат да изпратят пакет. Допустимите стойности за priority в HFSC и CBQ са от 0 до 7, като колкото по-високо е числото, толкова по-голям е приоритета. Също така priority влиза в сила когато връзката е натоварена и има опастност да не може да се изпълни принципа за гарантиране на минимална скорост.
• qlimit - брой "клетки" във FIFO опашка, използвана за запазване на изходящите пакети. Това се налага когато капацитетът на връзката не е достатъчен. В случай на насищане може да се случи някой от класовете да не може да предава. Тогава класовете запазват пакетите в определен брой клетки от паметта по реда им на пристигане. Когато се освободи ресурс, опашката ще бъде изпразнена навън. Използването на qlimit трябва да е само в крайни случаи, тъй като FIFO опашка противоречи на идеята за адаптивност и проспособимост на HFSC алгоритъма. Все пак запазване в паметта е по-добрата алтернатива от изпускане на пакети. Стойността на qlimit по подразбиране е 50.
• realtime - минимална гарантирана скорост, с която краен клас може да предава, независимо какво става с другите класове. Стойността на realtime може да бъде от 0% до 80% от общия капацитет на връзката.
• upperlimit - капацитет, който краен клас никога не може да надвиши.
• linkshare - същото като bandwidth, но важи само за вътрешните класове по йерархията. Ако за клас е сложена стойност на bandwidth, може да не се задава стойност за linkshare

Общ синтаксис за опашките в pf.conf:
altq on $interface $scheduler bandwidth $bw [priority $pri] [qlimit $qlim] queue { $q1, $q2, $q3...}}}

• interface - мрежовия интерфейс, където се инсталира дисциплината за обслужване
• scheduler - алгоритъм на планировчика
• bandwidth - капацитет на връзката. Задава се в b, Kb, Mb за bits, kilobits, megabits за една секунда. Стойността за подразбиране е 100% от капацитета на родителския клас.
• q1, q2, q3 ... - списък с имена на класове, които се описват по-долу

Общ синтаксис за описване на опашка (клас):
queue $name [on $interface] bandwidth $bw [priority $pri] [qlimit $qlim] $scheduler ( $sched_options ) { $queue_list }

• name - име на опашката. Трябва да съвпада с някое от имената на класовете, описани в списъка { $q1, $q2, $q3...} на родителския клас. Максималната дължина на името е 15 символа
• sched_options - допълнителни настройки и опции, които контролират поведението на планировчика
  • default - дефинира класа като клас в който попада всичкия некласифициран трафик. Трябва да има само една default дефиниция за всички класове, които са към един мрежов интерфейс.
  • red - активира алгоритъма Random Early Detection (RED) за опашката
  • ecn - активира алгоритъма Explicit Congestion Notification (ECN) за опашката
  • realtime $bw - задава параметъра realtime в HFSC
  • upperlimit $bw - задава параметъра upperlimit в HFSC
  • linkshare $bw - задава параметъра linkshare в HFSC

Примерна йерархия от класове

altq on rl0 bandwidth 744Kb hfsc queue { ack, dns, ssh, bulk, bittor, spamd }
queue ack bandwidth 80% priority 7 qlimit 500 hfsc (realtime 50%)
queue dns bandwidth 7% priority 6 qlimit 500 hfsc (realtime 5%)
queue ssh bandwidth 10% priority 5 qlimit 500 hfsc (realtime 10%) {ssh_bulk, ssh_login}
queue ssh_login bandwidth 90% priority 5 qlimit 500 hfsc
queue ssh_bulk bandwidth 10% priority 4 qlimit 500 hfsc
queue bulk bandwidth 1% priority 4 qlimit 500 hfsc (realtime 5% default)
queue bittor bandwidth 1% priority 3 qlimit 500 hfsc (upperlimit 99%)
queue spamd bandwidth 1% priority 2 qlimit 500 hfsc (upperlimit 1%)

Използвана литература

http://www.cs.cmu.edu/~hzhang/papers/SIGCOM97.pdf - A Hierarchical Fair Service Curve Algorithm for LinkSharing, RealTime and Priority Services
http://linux-ip.net/articles/hfsc.en/ - HFSC Scheduling with Linux
https://calomel.org/pf_hfsc.html - Hierarchical Fair Service Curve (HFSC) of OpenBSD
http://www.openbsd.org/faq/pf/queueing.html - PF: Packet Queueing and Prioritization

mencoder input.avi -ovc lavc -lavcopts acodec=ac3:abitrate=64:vcodec=mpeg4:vbitrate=300 -oac mp3lame -lameopts br=64 -vf scale=320:240 -of lavf -lavfopts format=mp4 -o output.mp4

Сега като го гледам този, не ми е чудно че не тръгва. Опитвам се да ползвам за аудио кодек АС3, а телефона май не го поддържа

mencoder input.avi -ovc x264 -x264encopts bitrate=350 -oac mp3lame -lameopts br=64 -vf scale=320:240 -o output.mp4

Едно време си мислех че x264 == MPEG-4, сега си мисля че не е точно така. Вече почнах да се обърквам кое е енкодер, кое е кодек и кое е контейнер...
Та това са само последните два от няколкостотин опита и килограми изхабени нерви по mencoder. Не искам да кажа че mencoder си върши работата зле - виновно е задклавиатурното устройство В други случаи mencoder върши чудесна работа, примерно това рипване на DVD:

mencoder dvd://3 -dvd-device /mnt/cdrom/ -ovc lavc -lavcopts vcodec=mpeg4:vhq:vbitrate="800" -oac mp3lame -lameopts br=128 -o dvd.avi

По едно време ми писна и се залових за алтернативния софтуер - ffmpeg. Не ми хареса man страницата му, където са описани по-малко от половината опции. Въпреки това, работата горе долу стана.
Първо пробвах да преобразувам клипчето в 3GP, но се оказа че формата има комплект валидни разделителни способности, най-високата от които да ми върши работа беше 176х144. Не мерси.
Съсредоточих се върху MP4:

ffmpeg -i input.avi -ar 8000 -ac 1 -acodec libfaac -vcodec mpeg4 -s 320x240 -r 24 -b 300000 -ab 48000 -t 30 output.mp4

Видеото излезе с подходящия thumbnail в мениджъра на телефона, даже и тръгна. Единствения кусур беше звука, който беше с отвратително качество.
Ето подобрение:

ffmpeg -i input.avi -ar 44100 -ac 1 -acodec libfaac -vcodec mpeg4 -s 320x240 -r 24 -b 250000 -ab 64000 output.mp4

Аудио енкодера не ми даде да вдигна аудио битрейта докато не вдигнах и sampling rate-а. Намалих и видео битрейта, понеже на някои места видеото забавяше и се получаваше framedrop ефект. Накрая всичко тръгна на сто процента

Опит 0 - Магазин 'First' се намира до компютърната зала 'First' (с два компютъра) и е от гаражния тип. В магазина нямаше никой. Аз се въртях пет минути, през които можех да изнеса половината инвентар, и все пак никой не дойде.

Опит 1 - Магазин 'Solaris' - видях че вътре се продават кабели и ел. инсталации, та си рекох че ще има и букси. Вътре ме посрещна една лелка:
- Добър ден.
- Добър ден, имате ли букси RJ-45? - питам аз.
- За какво са тези букси?
- Ами за LAN кабел, компютърна мрежа...
- Имаме букси за телевизори. Ако ви трябва нещо за компютъра не мога да ви помогна.
И толкова в магазин 'Solaris' Знам още няколко подобни магазина за кабели и ел. обзавеждане, в които щях да получа същия отговор.

Опит 2 - Магазин 'Millenium' - на центъра. Голям магазин - сглобяват конфигурации, продават аксесоари, има си и зала с 10-20 компютъра. (Сайта им изглежда не е поддържан от както е направен из 90-те години, но това само помага за схващането колко е древен и могъщ въпросния магазин). Имаше двама продавачи, мен ме пое едно момченце.
- Добър ден, имате ли RJ-45?
- Какво? - поглед тип 'заек пред фарове', явно беше нов.
- Букса RJ-45 търся.
Малкия отиде при някакъв чичка, който явно беше старши и му шепне:
- Имаме ли NJ-45? - ('енджи' си е същото като 'ержи', нали така...)
Чичката ме зяпна умно и само дето не чувам празния ход на механизмите в главата му. Вече взе да ми писва, та орязах десетина нива от техническата терминология:
- Букса за кабела си търся!
В този момент се включи продавач номер 3, който дочу че нещо се търси и схвана за какво става въпрос. Извади един кабел от някакъв switch и показа на първите двама за какво става въпрос. Младия захапа:
- Ааа, имаме такова! Колко искате?
- Ами колко струват? - бях излязъл с 2 лева в джоба и трябваше да ми стигнат за поне десетина, щото съм калпав кримпвач.
- 30 стотинки. - и избяга някъде отзад.
При такъв пладнешки обир само успях да кажа 'аз ей сега се връщам' и си излязох от магазина.

Опит 3 - Магазин 'Тодор Петров' в телевизионния сервиз. Ето това вече е магазин. В него има всичко. От дискретни елементи през интегрални схеми, сглобени изделия, car audio, уреди, кабели...
- Добър ден, какво ще желаете? - една от четирите продавачки.
- Десет букси Rj-45.
- Лев и двадесет, благодаря.
Всъщност в телевизионния сервиз има 3-4 магазина, всеки от които е така зареден. Само че въпросния ТВ сервиз ми е на половин час от вкъщи. Защо няма други нормални магазини за компютърна техника из града? В Пловдив само в един малък район около центъра и военна болница знам поне 20 места от където може да се намерят RJ-та...

Имаше вариант и за Опит 4 - магазин 'Викинг' на бул. Руски. Само че не съм очарован от тях - обслужване и цени, и ако не е въпрос на живот и смърт не бих стъпил вътре.
Сега се сещам и за номер 5 - магазина на 'MOST', където обаче не знам дали щях да намеря RJ-та.

Липсва ми Web Developer добавката от FF. Тук има нещо подобно - Tools -> Advanced -> Developer Tools, но е далече от версията на FF.
В заключение на сравнението Opera <> Firefox (без да усетя съм почнал да ги сбивам ) ще кажа че Opera ми изглежда като всичко добро от FF събрано на куп и на стероиди. Бързината на зареждане - ако някога FF стигне до там, ще стане революция.
И все пак навика си е навик, и ако в някой скорошен ъпдейт на FF оправят забиванията и memory usage-то - пак ще почна да си го ползвам.