None Mouse6 : PrevWorkspace
None Mouse7 : NextWorkspace

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

Какво е timelapse?
Това е кинематографска техника при която честотата на заснемане на кадрите е по-малка от честотата на възпроизвеждането им. Примерно ако една сцена се снима всяка секунда и после клипа се пусне на 30 fps резултатът ще бъде увеличаване на скоростта 30 пъти.

Какво е HDR?
Ако се абстрахираме от математиката и засуканите термини, можем разговорно да кажем че това е техника за получаване на равномерно осветен кадър (с изчистени преекспонирани и недоекспонирани области). Технологията стандартно използва три кадъра с различна експозиция (-2, 0, +2), които слива в един - изчистен.

Какво става като комбинираме HDR с timelapse?
Красиви клипчета

Как се прави HDR timelapse с CHDK?
CHDK не прави HDR - това се прави после от софтуера, който слива трите снимки на сцената. CHDK прави "bracketing" - автоматичното заснемане на трите кадъра с различна експозиция. Следвайте следните стъпки:
1. В менюто на CHDK изберете "Extra Photo Operations" -> "Bracketing in Continuous Mode". Там изберете "Tv bracketing" = 2EV, "Av bracketing" = OFF, "Bracketing type" = "+/-"
2. В менюто на фотоапарата изберете режим "Continuous Mode".
3. В менюто за самоснимачка изберете "Custom mode" със следните параметри: "Delay" = 0s, "Shots" = 3
От тук нататък пуснете кой да е intervalometer скрипт с параметри по избор. Какво ще се случи когато скриптът даде команда за снимане? Ще се задейства самоснимачката, която ще направи 3 последователни снимки с различна експозиция.

В края на сесията след няколко минути/часа ще имате X броя сцени с Х*3 броя изображения. Прехвърляте ги на компютъра и със следния скрипт получавате HDR-ите:

От тук нататък имате всяка сцена на HDR с име от типа hdr_shot_001.jpg. От тези трябва да се получи клипче.
Това става с mencoder:
mencoder mf://*.jpg -mf w=640:h=480:fps=15:type=jpg -ovc lavc -lavcopts vcodec=mpeg4:mbd=2:trell -oac copy -o output.avi
Тук 640 и 480 са размерите на снимките ви. Може да си поиграете с параметъра fps за да получите по-бързи или по-бавни клипчета.

Настоящата статия не претендира за изчерпаемост на темата, нито за професионализъм. Но пък претендира за най-лесния и бърз начин за създаване на HDR timelapse

И накрая резултата от едно пробно снимане:

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 и изходящите й връзки.

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

Има различни реализации на алгоритми за подобряване Качеството на услугата (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

• DEL се държи като BACKSPACE - трие знака от ляво на курсора
• при натискане на DEL се изписва ?^ или ?H или нещо подобно
• при натискане на DEL просто не се случва нищо

Изметох Гугъл за отговори какво става с мен и накрая се оказа че имам полтъргайст в контролера на клавиатурата.
Майтап Ама се оказа че проблема с клавишите DEL и BACKSPACE е толкова заплетен, че чак ми стана чудно как в Windows и Linux до сега не съм имал проблеми. Ето ви един примерен документ да прочетете за какво става въпрос.
Е, оказа се че тъпия проблем има тъпо решение. Във Vim командата

:fixdel

оправя всичко и съответно може да бъде добавена в ~/.vimrc
За csh има подобна магия и това е:

if ($term == "xterm" || $term == "vt100" || $term == "rxvt" \
|| $term == "vt102" || $term !~ "con*") then
# bind keypad keys for console, vt100, vt102, xterm
bindkey "\e[1~" beginning-of-line # Home
bindkey "\e[7~" beginning-of-line # Home rxvt
bindkey "\e[2~" overwrite-mode # Ins
bindkey "\e[3~" delete-char # Delete
bindkey "\e[4~" end-of-line # End
bindkey "\e[8~" end-of-line # End rxvt
endif
bindkey ^? delete-char # for console
bindkey ^[[3~ delete-char # for xterm

Идеята на последните два реда обезмисля целия if-endif блок преди това. При мен работи само така - и с двете неща накуп

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 ефект. Накрая всичко тръгна на сто процента

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