Tym razem Sun dał lekko ciała i ciągle nie zaktualizował dokumentacji Solarisa, ale prawdopodobnie w ciągu najbliższych dni szybko to nadrobi.

Oczekujących informacji na temat Linuksów, Solarisów czy innych Indiańców od razu z góry uprzedzę, że nic takiego tutaj nie będzie. W zasadzie wyjdzie z tego pewnie jakaś recenzja czytnika. Chciałem ją napisać wcześniej, ale ciągle brakowało czasu… I tym sposobem doczekałem się obiecywanego od kilku miesięcy nowego firmware’u – i taką wersję opisuję. Uwaga, wyjdzie pewnie długie. ;)

EDIT: poprawiłem trochę post, trochę bardziej zorganizowałem dołączyłem sekcję “jak to zrobić” – może komuś się przyda.

Wstępniak, czyli o co się w tym wszystkim rozchodzi?

Lubię czytać. Staram się, jak tylko jest możliwość, ale wiadomo jak to z czasem… Poza tym, co by nie mówić, książki, choć dają ten jedyny, niepowtarzalny “feeling”, zazwyczaj są niewygodne. Mniej bądź bardziej ciężkie, zajmują miejsce, bywają nieporęczne i tak dalej. Próbowałem czytać na laptopie – owszem, da się, ale mam awersję do wszelkiego typu “świecących” monitorów przy czytaniu dłuższych tekstów. Na dokładkę przy wyświetlaczach LCD męczę się szybciej niż przy monitorach CRT – są dla mnie zbyt kontrastowe. Mimo tego próbowałem czytać książki korzystając z PDA. Doszedłem do wniosku, że nawet ekran o rozdzielczości VGA tego nie ratuje – jest to za małe i zbyt nieporęczne. Od pewnego czasu przyglądałem się rozwiązaniom opartym o e-ink. W końcu przełamałem się i sprawiłem sobie jedno z takich urządzeń: Sony PRS-505.

Po wstępniaku, czyli co dostajemy do ręki?

Już wiedziałem po obejrzeniu wszelkich innych prezentacji, recenzji i tym podobnych, czego mniej więcej się spodziewać. Głównie na podstawie różnych recenzji poprzedniego modelu: PRS-500. Rozmiary tegoż urządzenia: 175 x 122 x 8mm (trochę większe niż format A6). Wymiary wyświetlacza: 123 x 91 mm (to z kolei troszkę mniej niż format A6). Waga, według oficjalnych materiałów (bez etui): 255g. O ile wymiary są mniej więcej takie, jak się spodziewałem, o tyle waga lekko mnie zaskoczyła – w pierwszej chwili wydawało się przyciężkie. W praktyce jednak nie męczy, trzyma się je bardzo dobrze nawet w jednej ręce. Wykonanie samego urządzenia bardzo na plus – czuć solidną robotę, wszystkie przyciski działają pewnie, nic nie trzeszczy, nie rozpada się. Cała obudowa jest z jakiegoś metalu (a przynajmniej metalizowana). Tyle plusów.

Etui? Kogoś powinni za to odstrzelić. O ile sam materiał jest jakoś tam akceptowalny (czymkolwiek to jest – przypomina jakiś skaj, od środka z kolei coś w rodzaju filcu), o tyle sposób spięcia go z czytnikiem jest straszny. Na grzbiecie okładki jest plastikowy uchwyt z dwoma “bolcami” od góry i od dołu, które wchodzą w odpowiadające im dziury w czytniku. Skutkuje to tym, że czytnik sobie lata, jak chce między jedną a drugą okładką. Sytuację lekko ratuje fakt, że w etui są ukryte małe magnesiki po rogach, które powodują, że okładka przylega do czytnika przy zamknięciu. Osobiście wolałbym, gdyby był w jakiś sposób mocowany “plecami” do jednej strony etui. Tak było zresztą w poprzednim modelu.
Z “usability” IMHO przydałoby się coś w rodzaju zakładki/kieszonki na kawałek kartki, notesika, czegokolwiek. Ale to takie tam moje marudzenie.

Popatrzmy bliżej…

Po obejrzeniu czytnika rzuca się w oczy: od góry wyłącznik, dwa sloty na karty (MS Pro Duo, jak na produkt Sony przystało, oraz SD), od dołu zawieszka do “smyczy” (naprawdę nie wyobrażam sobie kogokolwiek z czytnikiem noszonym na smyczy – ale różni ludzie, różne potrzeby…), mini-USB, gniazdo zasilania (brak zasilacza w komplecie), mini jack (do słuchawek), przyciski głośniej/ciszej. Na czytniku trochę guziczków – w zasadzie same się opisują. Całość moim zdaniem wykonana zgrabnie, estetycznie.

3, 2, 1… Odpalamy!

To, co spowodowało w pierwszej chwili po włączeniu natychmiastowy opad szczęki i problemy z pozbieraniem jej z podłogi, to wyświetlacz. Zdjęcia, jakiekolwiek by nie były (a że te obok nie grzeszą jakością pod jakimkolwiek względem, mam tego świadomość), nie są w stanie tego oddać.
Drugi opad szczęki zaliczyłem po otworzeniu przykładowych fotografii. Ja wiem, że można wiele, ale zdając sobie sprawę z tego, że ten wyświetlacz dysponuje 8 odcieniami szarości i stosunkowo niewielką rozdzielczością (ok. 800×600), to po prostu… WOW. Nawet komiksy wyglądają świetnie.

Wyświetlacz (z racji tego, że imituje papier) ma dość ciekawą właściwość – im jaśniej, im ostrzej oświetlony, tym bardziej czytelny i kontrastowy. Tło nie jest białe, lecz szare. Tak samo tekst nie jest czarny – jest ciemnoszary. Widać to na zdjęciach w porównaniu z książkami. Cecha ta może być irytująca przy złym oświetleniu, jednak przy jasnym wyświetlacz nabiera “blasku” i kontrastu. W świetle słonecznym wygląda wręcz cudownie. Faktura ekranu przypomina lekko pergaminowany papier. Chociaż sprawia wrażenie “błyszczącego”, nie działa jednak jak lustro, w związku z tym nie trzeba się zmagać w jakimś strasznym stopniu z refleksami światła. Występują mniej więcej w takim samym stopniu, jak właście przy papierze pergaminowanym.
Co jeszcze w nim ciekawego? Hm, wada – jest wolny. Zmiana ekranu trwa niecałą sekundę – ekran na moment robi się zaczerniony, po czym pojawia się właściwy obraz. Przy czytaniu moim zdaniem to nie przeszkadza, denerwujące jest przy poruszaniu się po menu. Na szczęście cyfry z boku działają w nim jak skróty (nie wyobrażam sobie przejeżdżanie strzałkami w celu wybrania konkretnej pozycji), po drugie czytnik buforuje wciśnięte klawisze – więc jeśli już się zna strukturę menu, to można w ciemno wcisnąć jakąś sekwencję i po prostu chwilkę poczekać. Po różnych forach można spotkać fanatyków, którzy twierdzą, że tego nie widzą. ;)

Jak tego używać?

Nie zamierzam robić tutaj przepisywać instrukcji, czy powielać to, co zostało napisane w setkach innych miejsc. Zresztą – obsługa jest prawie tak prosta, jak obsługa cepa.
Struktura menu – jak dla mnie jest dość proste, intuicyjne, bez zbędnych wynalazków. Zasadniczo mamy dostęp do książek – sortowanie po tytułach, po autorach, po “kolekcjach” (czyli tak naprawdę po tagach). Dla każdej książki mamy kontynuację czytania, skok na początek, koniec, spis treści, naszą “historię” czytania, zakładki, informacje o książce. Czytanie książki – guziczek “w prawo” – strona do przodu, guziczek “w lewo” – strona do tyłu, przytrzymanie któregoś kilka sekund, to skok o 10 stron we wskazaną stronę, wystukane cyferki zatwierdzone Enterem – skok do strony o podanym numerze. Kliknięcie “lupki” – zmiana rozmiaru tekstu, przytrzymanie “lupki” obrócenie całości o 90 stopni.
Oprócz tego z menu jest oczywiście dostęp do odtwarzacza muzyki i przeglądania grafiki. W ustawieniach możemy sobie ustawić aktualny czas, wyłączyć całkowicie czytnik (domyślnie jest tylko usypiany), przywrócić ustawienia domyślne, wybrać orientację (pionowa/pozioma). W ogólności – nic wyszukanego, ale doskonale spełniające rolę, do jakiej zostało zaprojektowane.

A gdyby tak generować losowe hasło w skrypcie kończącym instalację i zapisywać je gdzieś w bezpiecznym miejscu/wyświetlać/cokolwiek sobie użytkownik wymyśli? Pomysł genialny, wydaje się prosty i… się sporo naszukałem, jak wygenerować odpowiedni “hash” hasła na etapie instalacji systemu. Oświecenie przyszło trochę później – przecież w tym momencie w /a mam już zainstalowany system. Powstał w związku z tym kawałek takiego przykładowego (o dziwo działającego), chociaż niezbyt ładnego kodu do skryptu kończącego instalację:

### Password generation

while [ "X${inst_name}" = "X" ]; do
    printf "*** Enter /etc/nodename: "
    read inst_name
done

echo ${inst_name} > /a/etc/nodename

inst_date=`date +"%Y/%m/%d %H:%M"`

echo "Generating password for ${inst_name}.."
PASS=`dd if=/dev/urandom bs=512 count=100 2> /dev/null | digest -a md5 | awk ´{print substr($1,2,10)}´`
HASH=`/a/usr/sfw/bin/openssl passwd -1 ${PASS}`

echo "hostname                  inst. date       password  "
echo "-----------------------------------------------------"

printf "%-25s %-16s %-10s\n" "${inst_name}" "${inst_date}" "${PASS}"

ed -s /a/etc/shadow <<EOF
,s#^root:[^:]*#root:$HASH#
w
q
EOF

# set the flag so sysidroot won't prompt for the root password
ed -s ${SI_SYS_STATE} <<EOF
g/# root password/s/^./1/
w
q
EOF

Co z tym dalej? A to już Twoja, czytelniku, inwencja…

root@ant:~# tcpdump -i eth0 -s 1500 -v -c 1 'ether [20:2] = 0x2000'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
21:53:10.844569 CDPv2, ttl: 180s, checksum: 692 (unverified), length 471
        Device-ID (0x01), length: 19 bytes: 'sw4k-0.xxxxxxxxxxxxxx'
/.../
        Port-ID (0x03), length: 19 bytes: 'GigabitEthernet4/48'
/.../

Pod Linuksem sprawa jest względnie prosta – tcpdump rozumie pakiety CDP i jeśli tylko odpowiedni przechwycimy, to wyświetli nam wszystkie potrzebne zazwyczaj informacje. Trochę gorzej jest pod Solarisem – chociaż snoop jest potężnym narzędziem, to akurat pakietów CDP nie rozumie. Pozostaje nam posłużyć się jakimś zewnętrznym narzędziem. Powodzenia w szukaniu – mi udało się znaleźć tylko coś takiego.
Z racji, że fajnie byłoby mieć takie polecenie w systemie, które nie wymaga uczenia się magicznej składni polecenia do sniffowania ruchu, wziąłem powyższy skrypt, poprzerabiałem go trochę (autor twierdzi, że działa pod Solarisem – nie wiem jakim cudem, mi OOTB nie chciał) i niniejszym powstała moja wersja tegoż skryptu:

root@ant:~# uname -a
Linux ant 2.6.24-16-386 #1 Thu Apr 10 12:50:06 UTC 2008 i686 GNU/Linux
root@ant:~# ./cdpinfo.pl -i eth0
Switch: sw4k-0.xxxxxxxxxxxxxx
Port:   GigabitEthernet4/48
VLAN:   527

server2.netinstall.srv:root ~ > uname -a
SunOS server2.netinstall.srv 5.10 Generic_127112-10 i86pc i386 i86pc
server2.netinstall.srv:root ~ > ./cdpinfo.pl -i nge0
Switch: sw6k5.adm.xxxxxxxxxxxxxx
Port:   GigabitEthernet9/22
VLAN:   66

Nie jest on całkiem idiotoodporny, nie jest najpiękniejszy i mocno wierzy w inteligencję ewentualnego użytkownika. Ale pomimo tego: SOA#1. U mnie wylądowało wśród pomocnych skryptów instalowanych domyślnie z Jumpstartu/Kickstartu. Może komuś się jeszcze przyda (o ja, naiwny…). Jakby ktoś jednak miał jakieś uwagi, pomysły, pretensje, cokolwiek – wie, gdzie mnie szukać.

solaris.srv:root ~ # zpool import pula
cannot mount 'pula/fs': Operation not supported
Apr 16 19:51:58 solaris.srv zfs: Mismatched versions:  File system is version 2 on-disk format,
which is incompatible with this software version 1!
solaris.srv:root ~ # zpool upgrade
This system is currently running ZFS version 4.

All pools are formatted using this version.
solaris.srv:root ~ # zfs list
NAME                                           USED  AVAIL  REFER  MOUNTPOINT
pula                                          3,38T  6,44T  23,5K  /pula
pula/fs                                       3,35T  6,44T    18K  /pula/fs
pula/fs/d001                                  56,8G  6,44T  22,7G  /pula/fs/d001
/.../
solaris.srv:root ~ # uname -a
SunOS solaris.srv 5.10 Generic_127128-11 i86pc i386 i86pc
solaris.srv:root ~ #

A poniżej skrótowa charakterystyka serwerków z rodziny x86:

• X4100/X4200/X4500 – tam mamy ILOM. I to jedyny sprzęt z kategorii x86, gdzie zarządzanie jeszcze mi się podoba. Jest w miarę proste, spójne, takie, jak powinno być W /SP mamy zebrane wszystkie rzeczy związane z SP, w /SYS – z serwerem. Intuicyjne. Trudno mi się do czegokolwiek przyczepić.
• X2100M2/X2200M2 – OK, to najtańsze możliwe serwerki w ofercie Suna chyba. Dobrze, że przynajmniej mają zarządzanie (w postaci ELOM) w przeciwieństwie do ich poprzedników, gdzie było to opcją. Ale czy naprawdę konieczne były utrudnienia w postaci totalnego przeorganizowania? Po cholerę rezygnować z /SYS i wrzucać to wszystko w bliżej nieodgadnione miejsca w /SP? Po co zmieniać standardowe od lat wyjście konsoli z ttya/9600 na ttyb/115200? W ostatnim firmware przynajmniej prędkość poprawili… Ale ttyb zostało. Tak, wiem, że 9600 to cholernie wolno, ale dopóki większość systemów domyślnie używa takiej prędkości, to ja bym zostawił i nie mieszał.
• Stare, już od jakiegoś czasu EOL, ale jeszcze przez niektórych używane v20z/v40z – pierwsze sunowe serwery x86 z całkiem jeszcze innym SP. Wybaczmy im tę pomyłkę, uczyli się jeszcze…
• X4150 – porażka na całej linii – tak, tu też mamy ELOM. Totalnie inny od tego poprzedniego. Żeby było śmieszniej – niech ktoś mi wyjaśni różnicę między jednym i drugim:
  
/SP/network -> set IPAddress=10.10.10.10
set 'IPAddress' to '10.10.10.10'
/SP/network -> set IPAddress=10.0.100.50
Invalid IP
Could not set 'IPAddress' to '10.0.100.50'

  Oczywiście nie rozumiem też, czym kierował się producent, że losowe modele mają w BIOS-ie w ogóle wyłączone “przypięcie” konsoli, SP, cokolwiek do konsoli szeregowej. Bo po co? Żeby było śmieszniej konsola “szeregowa” wewnątrz działa na ttyb/115200. Nie, nie da się tego zmienić. Tak, admin może sobie przytargać monitor i klawiaturę, podpiąć, w BIOS-ie to sobie wyklikać. Tylko kto przy takim sprzęcie używa klawiatury i monitora? Owszem, w większych serwerowniach zazwyczaj jest jeden/kilka większych KVM-ów dostępnych po sieci. Ale przecież Suny mają te swoje fantastyczne interfejsy dostępne przez WWW, po co ktoś będzie ciągnął tam jeszcze dodatkowy kabelek, żeby podpiąć się pod KVM-a, tylko po to, żeby włączyć przekierowanie?

Prowadzi to do sytuacji, że jak widzę kolejny serwer Suna spod znaku x86, to powoli zaczynam mieć strach przed włączeniem go do prądu. Bo nie wiadomo, czym tym razem zaskoczy.
Już nie wspominam o nakładzie czasu niezbędnym na przeszkolenie siebie i innych z obsługi tych konsol… Bo weź tu potem pamiętaj w sytuacji kryzysowej, że ta maszyna to jest konkretnie x4150 i trzeba zrobić “start /SP/AgentInfo/Console”, a ta druga to x4100 i trzeba “start /SP/console”, a ta trzecia to stare v20z i należy wklepać “platform console”. I że z tego ostatniego ucieka się z powrotem do SP kombosem godnym emacsowca (nie ubliżając im), a w poprzednich jeszcze inaczej. Owszem, jest to w dokumentacji. Tylko w przypadku awarii nikt nie ma czasu tego szukać.
Sparci… Tak, tu jest zdecydowanie spójniej. Chociaż przy ostatnich Niagarach (T5×20/T5×40) ktoś wpadł na pomysł wpakowania ILOM-a. Oczywiście to jeszcze inny ILOM niż ten chociażby w Thumperach, a jakże. Dobrze przynajmniej, że jest tryb “emulacji” ALOM-a.

No, ulżyło mi. A w ramach prezentu urodzinowego i chwalenia się jakiś czas temu sprawiłem sobie drugą część poprzedniego prezentu, czyli “Solaris Internals”. Od razu lepiej. ;)

UPDATE:
Narzekałem wyżej na X4150? To ponarzekam do końca. Zrobiłem upgrade firmware’u do najnowszej wersji. Wzięli mnie z zaskoczenia, wewnętrzna konsola szeregowa nagle zrobiła się ttyb/9600. Ale jakby mało było niespodzianek:

unknown console login: Input Char: 72
rInput Char: 6F
oInput Char: 6F
oInput Char: 74
tInput Char: D

Password:

Komuś przy wypuszczaniu BIOS-u chyba zapomniało się jakiś debug wyłączyć…

UPDATE2:
Na chłodno przejrzałem posta jeszcze raz i nie żałuję niczego, co tu napisałem. Mało tego, poprawiłem i dopisałem jeszcze parę rzeczy. A jak już narzekać, to na całego, a co!

^*) Niepotrzebne skreślić.

I niech nikt nie mówi, że sysadmini nie umieją się bawić… ;)

Example 1: Example 1: Using the mpt Configuration File

Create a file called /kernel/drv/mpt.conf, then add the fol-
lowing line:

scsi-options=0×78;

The above example disables tagged queuing, Fast/Ultra SCSI,
and wide mode for all mpt instances.

Powodzenia w szukaniu w manualach, czemu konkretnie ta wartość odpowiada konkretnie tym opcjom.
Odpowiedź można znaleźć w /usr/include/sys/scsi/conf/autoconf.h

/*
 * SCSI subsystem options
 */

/*
 * Following are for debugging purposes (few Sun drivers support this)
 */
#define SCSI_DEBUG_TGT  0x1     /* debug statements in target drivers */
#define SCSI_DEBUG_LIB  0x2     /* debug statements in library */
#define SCSI_DEBUG_HA   0x4     /* debug statements in host adapters */

/*
 * Following are applicable to all interconnects
 */
#define SCSI_OPTIONS_LINK       0x10    /* Global linked commands */
#define SCSI_OPTIONS_TAG        0x80    /* Global tagged command support */

/*
 * Following are for parallel SCSI only
 */
#define SCSI_OPTIONS_DR         0x8     /* Global disconnect/reconnect  */
#define SCSI_OPTIONS_SYNC       0x20    /* Global synchronous xfer capability */
#define SCSI_OPTIONS_PARITY     0x40    /* Global parity support */
#define SCSI_OPTIONS_FAST       0x100   /* Global FAST scsi support */
#define SCSI_OPTIONS_WIDE       0x200   /* Global WIDE scsi support */
#define SCSI_OPTIONS_FAST20     0x400   /* Global FAST20 scsi support */
#define SCSI_OPTIONS_FAST40     0x800   /* Global FAST40 scsi support */
#define SCSI_OPTIONS_FAST80     0x1000  /* Global FAST80 scsi support */
#define SCSI_OPTIONS_FAST160    0x2000  /* Global FAST160 scsi support */
#define SCSI_OPTIONS_FAST320    0x4000  /* Global FAST320 scsi support */

/*
 * the following 3 bits are for being able to limit the max. number of LUNs
 * a nexus driver will allow -- "default" means that the adapter will
 * continue its default behaviour
 */
#define SCSI_OPTIONS_NLUNS_MASK         (0x70000)

#define SCSI_OPTIONS_NLUNS_DEFAULT      0x00000
#define SCSI_OPTIONS_NLUNS_1            0x10000
#define SCSI_OPTIONS_NLUNS_8            0x20000
#define SCSI_OPTIONS_NLUNS_16           0x30000
#define SCSI_OPTIONS_NLUNS_32           0x40000

#define SCSI_OPTIONS_NLUNS(n)           ((n) & SCSI_OPTIONS_NLUNS_MASK)

#define SCSI_OPTIONS_QAS        0x100000 /* Global Quick Arbitration Select */

Jeszcze jakby kogoś interesowało, to domyślnie w s10u4 scsi-options=0×107ff8 (zarówno na sparcu, jak i x86). Powodzenia w zmienianiu. :)

Wiem, że niżej zamieszczam test typowo syntetyczny, wiem, że to nijak musi się przekładać na faktyczne warunki “bojowe” (i zapewne się nie przekłada), niemniej jednak liczby robią wrażenie:

niagara2.dev:root ~ > openssl speed rsa1024 -engine pkcs11
engine "pkcs11" set.
Doing 1024 bit private rsa's for 10s: 15509 1024 bit private RSA's in 0.60s
Doing 1024 bit public rsa's for 10s: 29934 1024 bit public RSA's in 0.90s
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29)
built on: date not available
options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) aes(partial) blowfish(ptr)
compiler: information not available
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
                  sign    verify    sign/s verify/s
rsa 1024 bits   0.0000s   0.0000s  25848.3  33260.0


Dla porównania analogiczne testy ze stojącego akurat obok X2200M2 (w środku 2 razy Opteron 2220 z zegarem 2,8GHz):

x2200m2.dev:root ~ > openssl speed rsa1024 -engine pkcs11
engine "pkcs11" set.
Doing 1024 bit private rsa's for 10s: 5364 1024 bit private RSA's in 10.00s
Doing 1024 bit public rsa's for 10s: 71792 1024 bit public RSA's in 9.99s
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29)
built on: date not available
options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,cisc,16,long) aes(partial) blowfish(ptr)
compiler: information not available
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
                  sign    verify    sign/s verify/s
rsa 1024 bits   0.0019s   0.0001s    536.4   7186.4


Tak, wiem, że T2 ma 8 rdzeni, w przypadku Opteronów sumarycznie z dwóch procesorów miałem “aż” cztery. Ale nie w tym jest siła. Wyniki dla jednego wątku openssl, najpierw T5220:

niagara2.dev:root ~ > openssl speed rsa1024 -engine pkcs11 -multi 1
engine "pkcs11" set.
Forked child 0
+DTP:1024:private:rsa:10
+R1:15470:1024:10.00
+DTP:1024:public:rsa:10
+R2:32576:1024:10.01
Got: +F2:1:1024:0.000647:0.000307 from 0
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29)
built on: date not available
options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) aes(partial) blowfish(ptr)
compiler: information not available
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used:
                  sign    verify    sign/s verify/s
rsa 1024 bits   0.0006s   0.0003s   1545.6   3257.3


Oraz Opteron:

x2200m2.dev:root ~ > openssl speed rsa1024 -engine pkcs11 -multi 1
engine "pkcs11" set.
Forked child 0
+DTP:1024:private:rsa:10
+R1:5337:1024:9.99
+DTP:1024:public:rsa:10
+R2:71640:1024:10.00
Got: +F2:1:1024:0.001873:0.000140 from 0
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29)
built on: date not available
options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,cisc,16,long) aes(partial) blowfish(ptr)
compiler: information not available
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used:
                  sign    verify    sign/s verify/s
rsa 1024 bits   0.0019s   0.0001s    533.9   7142.9


To o co chodzi? A o to, że w T2 mamy jednostkę MAU (Modular Arithmetic Unit) – a dokładniej 8 takich (po jednej na rdzeń). Zalążek tego mieliśmy już w T1, (tak samo, po jednej jednostce MAU na rdzeń), przy czym tam mieliśmy tylko wsparcie dla algorytmów RSA, DSA oraz Diffie Hellman. W T2 dochodzi nam do tego jeszcze AES, 3DES, RC4, SHA1, SHA256, MD5, ECC. Robi wrażenie. :)

Na zakończenie dwie tabelki: pierwsza obrazuje liczbę “podpisów” dla RSA1024 w zależności od liczby wątków równoległych – widać, jak ładnie T2 się “wątkuje”:

Druga przedstawia liczbę “podpisów” dla RSA${i}, gdzie ${i} przyjmuje wartości 512, 1024, 2048, 4096 – tu z kolei widać, gdzie się kończy wsparcie MAU dla biblioteki PKCS11 (dla obydwu serwerów przyjąłem “-multi 32″):

Na koniec “disklejmer” – wszędzie powyżej używałem “-engine pkcs11″ z dwóch powodów – po pierwsze, software’owe algorytmy dla RSA w tej bibliotece wyglądają na wydajniejsze od standardowej zawartej w OpenSSL, po drugie, tylko w ten sposób mogę zrobić pożytek z akceleracji sprzętowej – libpkcs11 zapewnia obsługę odpowiednich providerów dostarczanych przez kernel Solarisa.