[Solved] Gigabites hálózat (Samba)

Hálózatok általános

Sziasztok!

Már vagy 2 hónapja ások egyre mélyebbre egyre tobb dolgot kipróbálva, de továbbra se sikerül 300Mbit fölé menni.
FTP-vel már elértem 60MiB/s tartós sebességet, de a Sambával jóesetben 35MiB/s, tehát fizikailag lehetséges kb megduplázni.
Iperf kb 500Mbit/s-eket méreget, ami nagyjából egyezik az FTP-vel. Közel sem az igazi, de sokkal jobb, mint ami most van.

Otthoni szerverről van szó, amin Ubuntu Server 9.04 x32 fut rajta pedig: Samba, Apache+PHP+MySQL (webfejlesztésre + 1-2 proginak), Torrentflux-b4rt.

A kliensen Windows7 x64 szorgoskodik tele mindenfélével. Kezelhetjük Vistaként is...

Az Ubuntu szerver hardver:
Alaplap: ASROCK ALiveNF6G-GLAN (Giga PHY Realtek RTL8211B, forcedeth modullal megy elvileg)
CPU: AMD Athlon 64 X2 5050e RAM: 1x Kingmax DDR2 1GB (Nem hiszem, hogy ez a kettő akadály lenne)
HDD: 2x Hitachi 500 GB SATA-II 7200 RPM 16 MB (szoftveres RAID1-ben) és WD 1000 GB SATA-II 7200 RPM 16 MB
(Mindőjükön NTFS partíció van NTFS-3g-vel mountolva, mert 1: már megvoltak a Linux előtt, 2: próbálkoztam ext3-mal, de csak póruljártam vele)
- A rendszer HDD: Maxtor 160GB ATA 5400 RPM (torrrent is ide dolgozik, bőven megfelel)

A Win7 kliens hardver:
Alaplap: Gigabyte P35-DS3R (Realtek RTL8168B/8111B NIC (NDIS 6.0))
CPU: Intel Core2 Duo E8400 RAM: 8x Kingston DDR2 2GB (Ez kettő se hiszem, hogy akadály lenne :)
HDD: Az előbbiekhez hasonlóak, de van egy SSD is, úgyhogy a sebesség nem lehet gond.

Switch: D-LINK DGS-1005D Kábelek: Szervertől switchig Cat5, switchtől a kliensig Cat6.
(A net és a többi kliens a routerre (DNS is) megy és a router 100Mbit vonalon jön a switchre.)

Van egy D-Link DGE-528T hálózatikártyám is, amit kipróbáltam mindkét gépben (Linuxon a beépített r8169 modullal megy, Win-re meg van driver).
Szinte semmi változást nem hozott. A forcedeth-re gyanakdotam, ezért vettem. Jelenleg a kliens gépben van. Amikor a Win7 újrakonfigurálja a hálózatot, ha valami nagy változást eszközölök, akkor az első másoláskor néha megy 50-60MiB/s-el, de ha utána elindítok egy újabb fájlt, akkor az már a szokásos 35MiB/s.
Ezek a Win Intéző által kiírt sebességi adatok (Totalcommander méglassabb), de nézegettem a Resoruce Monitort is és az is ennyit ír, csak Mbit/s-ben mér (250-300Mbit/s max).
De lehetséges ez az első másolás gyorsabb dolog csak illúzió ugyanis írt már 97MiB/s-t is egyszer, ami fizikailag lehetetlen, sőt ugyan gépen belül volt, de írt 200-300MiB/s-t is, amit még az SSD se tud, de ez SATA-II volt SATA-II-re...

További furcsaság, hogy a kliens gépen belül is NTFS-ről NTFS-re is kb 35-40MiB/s a másolás. NTFS vagy explorer.exe korlát lenne?
Viszont a VMware villámgyors, pedig próbáltam hálózatról is megnyitni virtuális gépet, de az piszok lassú volt. Tehát, ha direktben is csak ennyi lenne az NTFS határa, akkor itt is lassú lenne. Ráadásul Total commander is tud 80MiB/s-el másolni, ami a fizikai határ kb. Talán az explorer.exe ilyen csacsi?
Hálózatra nem jó a Total commander, csúnya 10MiB/s alatt van.

Leteszteltem Ubuntu Jaunty 9.04 LiveCD-vel is a dolgokat. A hálózat ugyanilyen max 35MiB/s.
Felmountolva két NTFS winyót a másolás 64MiB/s, tehát tudna többet kezdeni az NTFS-sel...
Főleg, hogy mint említettem proFTP-vel megvan ez a 60 mint a szél.

Amíg nem muszály nem szeretnék megvállni az NTFS-től ugyanis ez kaphat hideget, meleget, áramszünetet, ami elő-előfordul és nincs szünetmentesem.
Tudom, hogy az NTFS nem Linux alá való, próbálkoztam is ext3-mal, de elkapott egy áramszünet éjszaka és kifeküdt mindkettő, amit este csináltam, azaz én hoztam létre és nem a telepítő még az elején (folyton busy volt, meg felismerhetetlen filesystem, sőt még a check se futott le rajtuk, mert az se ismerte fel, úgyhogy NTFS vissza került).
Valószínű, hogy én hibáztam el valamit, de amíg ennyi tehetségem van a linux fájlrendszerehez inkább nem kozkáztatok. Pl két winyót linear RAID-be raktam, mert mért ne, és át akartam méretezni a partíciót, mert az nem terjedt át (előtte persze minden gondosan leteszteltem virtuális gépen), hát persze, hogy elszállt a partíciós táblám. Szerencsére csak 1TB sorozat volt, amit úgyse nézek újra csak szokásból tartottam meg. Emlékeimben örökké élnek. :)

Más gurukkal is beszéltem már erről és szerintük az ifconfig és ethtool rendben van.
Az MTU 1500, ami a max érték az ethernetnél, úgyhogy ezen se tudok emelni.
1000 Mbps/s full a kapcsoalt és az autonegotiation aktív. A linux nem tudja kikapcsolni az alaplapin.

A Windowson a DGE-528T-n beálíltottam autoneg helyett 1Ggp/s-t.
Nagy tuning volt még Win részről ez a két registry bejegyzés:
NetworkThrottlingIndex -> 0xffffffff (4294967295)
SystemResponsiveness -> 0x00000064 (100)

Jumbo frame-ről a nevén kívül mást nem tudok, de ha megoldható ezzel a rendszerrel az is jó lenne. :)

IPV6 tiltással is próbálkoztam, nem segített.
A Samba alábbi opcióival is mindenféle kombinációban próbálkoztam, sikertelenül:
socket options = SO_KEEPALIVE TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=65536 SO_RCVBUF=65536
read raw,write raw, oplocks, logolás alacsony értéken
wins szerverként is próbáltam
domainhez rendelve nincs, netbios névről, vagy IP-ről érem el

A samba config fájlom így néz ki:
[global]
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
obey pam restrictions = yes
write list = lightning,@lightning
deny hosts = 0.0.0.0/0
passwd program = /usr/bin/passwd %u
max xmit = 65536
allow hosts = 127.0.0.1 192.168.1.0/24
netbios name = server
oplocks = yes
default = global
local master = yes
workgroup = WORKGROUP
os level = 20
debug level = 1
usershare allow guests = yes
getwd cache = yes
max log size = 1000
log file = /var/log/samba/log.%m
read raw = yes
write raw = yes
read list = home,@home
socket options = SO_KEEPALIVE TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=65536 SO_RCVBUF=65536
map to guest = bad user
encrypt passwords = true
passdb backend = tdbsam
dead time = 15
server string = HomeServer
path = /media
unix password sync = yes
valid users = lightning,home,@lightning,@home
syslog = 0
panic action = /usr/share/samba/panic-action %d
pam password change = no

[sample-share]
valid users = lightning,home,@lightning,@home
read list = home,@home
write list = lightning,@lightning
path = /media/md0p1/
vfs object = recycle
recycle:repository = /media/md0p1/.recycle
recycle:keeptree = Yes
recycle:touch = Yes
recycle:versions = Yes
recycle:maxsize = 0
recycle:exclude = *.tmp *.temp *.o *.obj ~$* *.~?? *.bak *.lck *.vmem

A /etc/network/interfaces fájl:
auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1
broadcast 192.168.1.255

A /etc/resolv.conf fájl:
nameserver 192.168.1.1

Aki megoldja a rejtélyt, annak imába foglalom a nevét! :)

  • 7154 megtekintés

( informer v | 2009. 07. 09., cs – 09:32 )

Szia,
hmmm tehát akkor sambával tartósan 35 MiB sebesség?

Ez azért több mint a 100BaseTX de mégsem annyi mint az ftp-s 60MiB ami ugye kb a soft RAID vége lehet. APROPOS! Csinálj már lécci egy dd if=/dev/zero of=/dev/md0/bigfile.raw bs=1M count=10000 -ret! Természetesen az output az nem konkrétan ez de oda mutasson, hogy tuti a tömbre menjen. Akkor kb tudjuk mire képes az architectura a RAID.

Samba szempontjából én többet hagytam a buffernak:
socket options = TCP_NODELAY SO_RCVBUF=524288 SO_SNDBUF=524288

mondjuk RAM is van bőven de szerintem 1 user esetén az 1GB-ba is el kell férnie kényelmesen.

Szerintem samba illetve smb hálózat érzékeny a név (wins) feloldásra is. Tehát legyen wins server a hálózaton és legyen rendbe a DNS / ReverseDNS kérdés is akár ha csak a host file erejéig is.

Nekem ha a kliens MS Vista és a hdd-je WD RAPTOR ugyanakkor a server böszme RAID (ami kb 270MiB -tal tud írni, és a hálókártyák intel PCI-E -sek akkor:

vistarol serverre igen változó 120MiB - 87MiB között
serverről vistára átlag 87MiB

Ez csak nagy file-okra vonatkozik! Kis file-ok esetén ez visszaesik 40-49MiB környékére!

Micsoda részvétel. :) Köszönet érte.

Igen átlag 35 MegaByte/sec a sebesség. Az NTFS határa pedig 64 MegaByte/sec (liveCD-vel a kliensgépben), ugyanígy a szerverben is, úgyhogy hardveres RAID nélkül ennél több valóbban nem is lesz, de már az is sokkal jobb lenne. Ehhez a 64-hez teljesen reális az FTP 60-as sebessége. De az 1TB-s WD nincs RAID-ben és róla is ugyanannyi a sebesség mint a RAID tömbről. Néha gyorsabb is a RAID, mert az próbálkozik elosztani a terhelést a winyók között. Persze jobb lenne 4x2TB hardveres RAID10-ben, de nincs ennyi pénzem. Néha pottyan egy-két webfejlesztési munka, de nagyrészt csak magamnak dolgozok, hisz még a gimit se fejeztem be és a pénz a két 24-es monitorra meg a kliensgépre ment nagyrészt még tavaly. :D

Az ext3-mas rendszer vinyóról is ugyanennyi a sebesség, de az sose lesz 60, ugyanis a hdparm szerint a winyó fizikailag max 54MiB/s-t tud és nem 80-90-et mint Satás barátai.

Ezeket eszközöltem most:
socket options = SO_KEEPALIVE TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=524288 SO_SNDBUF=524288
#ha kevés lenne a RAM a kliensből nyugodtan átdobhatok 2GB-t, úgyis maradna 6GB, de bőven elég a Linuxnak ez az 1GB is....
#A max xmit értéke jó? Próbáltam 65536-tal és 65535-tel is, elvileg az utóbbit tudja a Vista és Win7 max.
wins support = true
#sok helyen láttam, hogy yes-t írnak true helyett, de a webminnel bekapcsolva true-t ír, úgyhogy maradtam ennél
name resolve order = wins lmhosts hosts bcast

Minden a régi...

Tudom, hogy hülyeség és a linuxxal kéne, de szoktam hálózaton keresztül egyik winyóról a másikra is másolni, tehát a kliens közvetít. Pl a torrentesről a filmesre. Kényelmesebb, egyszerűbb, stb. A lényeg, hogy így kb 10 MiB/s a sebesség. Értem én, hogy így befelé és kifelé is forgalom van, de a full duplex nem kéne, hogy egyszerre engedje őket, tehát 30/30MiB sebességgel?

A Realtekről én is tudom, hogy kaki, de szinte minden integrált lan és audio reltek...
Esetleg vehetnék még egy D-Link DGE-528T-t és, akkor mindkét gépben ilyen lenne. +A switch is D-Link. Kész família.
De amíg nincs kizárva minden szoftveres nyúg nem szívesen költök megint.

a realtek csipes kártyát miért forcedeth hajtja? nem megy r8169 vagy ilyesmi driverrel?
amőgy javaslom realtek oldaláról letöltött és fordított drivert kipróbálni, mert az ubuntuban lévő r8169 konkrétan az bizonyos kártyáknál nagyon szar. (pl. nekem 8168-at eleinte meg se hajtotta (pedig hivatalosan de), aztán később már megszólalt vele, de valami borzasztó gyengén. a realtekes gyári driver fényévekkel jobb nekem.) egy próbát megér. ezen múlik minden. ha szar a hálókártya drivere, akkor onnantól nem tudsz mit csinálni.

----------------------------------
feel the beat - it's everywhere!

( Hyperion | 2009. 07. 09., cs – 11:27 )

Sziasztok!

Csatlakozom Én is ehhez az anomáliához. Nekem sem sikerül ennél többet kisajtolni.. Linksys SLM2005 switchek + intel gigabites kártyák, Cat 6 kábellel.. Debian -> XP-k között..

( kz86 | 2009. 07. 09., cs – 11:29 )

Nekem nagyon rossz tapasztalataim vannak a samba+realtek chip-es hálókártya párosítással. Kliens és szerver oldalon is.

Mindkettő. Volt pl egy olyan, hogy beállítottam egy új gépet amin többek között egy dosos könyvelő program futott sambáról. Aztán használat közben kiderült, hogy valamivel lassabb is és még ki is dobálja őket naponta többször. Egy hétig keresgéltem neten, hogy mi lehet a probléma, logokat nézegettem, az alaplapi hálókártya mellé betettem egy másikat, ami szintén realtek chipes volt, és azzal is ugyanez volt a probléma. Utána 1 hét múlva egy másik irodába bekerült egy hasonló gép, de ezen már használhatatlanul lassú volt. Na mondom akkor átrakom a régiből a hálókártyát, amibe intel kártya volt. Rögtön eltűnt a probléma. A másikba is beraktam egy ilyen kártyát és azóta is boldogan használják:)

Másik helyen a szerverben lévő gigabites realtek kártya lassab volt, mint a régi 100Mb-es intel. Azóta ha bármilyen gépet csinálok az az első, hogy letiltom az alaplapi realtek fost és belerakok egy normális hálókártyát.

( samuf v | 2009. 07. 09., cs – 12:28 )

Az FTP udp vagy tcp csomagokat használ?
A másik amit megnéznék, hogy mekkorák a TCP csomagok másolás közben, esetleg változtatnák a min és max méreten. Jelenleg milyen értéken állnak? (/proc/sys/net/ipv4/tcp_[w/r]mem)

Végeztem egy kis tesztet..:

Szerver memóriából -> kliens memóriába írás (dd if=/dev/zero... | netcat 10..... 1000) 92MB/s (Ez szerintem meggyőző..)

Szerver HDD -> kliens hdd-re írás: 52MB/s (Egyértelműnek tünik, hogy a gépek a gépek teljesítménye nem megfelelő, nem a hálózaté)

Samba szerver HDD -> Kliens HDD-re írás: 19-24MB/s (Ez viszont siralmas.. ennyire lerontja a samba, vagy konfighiba nemtudom.)

Ennyi.. nem vagyok elégedett :/

Szerintem túl alacsonyak az értéke, van rá valamilyen számítási mód, hogy mekkorának kell lenni. Ha lesz egy kis időm megkeresem.

szerk:
Valami ilyesmi kellene
/etc/sysctl.conf
# increase TCP max buffer size setable using setsockopt()
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# increase Linux autotuning TCP buffer limits
# min, default, and max number of bytes to use
# set max to at least 4MB, or higher if you use very high BDP paths
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

You should also verify that the following are all set to the default value of 1

sysctl net.ipv4.tcp_window_scaling
sysctl net.ipv4.tcp_timestamps
sysctl net.ipv4.tcp_sack

Szoknom kell még ezt HUP-like post rendszert... Feljebb van még egy postom...

Én is lemértem ezt a két dolgot:
tcp_wmem: 4096 16384 3514368
tcp_rmem: 4096 87380 3514368

A /etc/sysctl.conf fájlt beállítottam úgy, ahogy írtad újraindítottam a hálózatot.
Semmi sem történt...

Oh. Megtörtént ez is. Új értékek beállítva. Le is ellenőriztem.
De a sebességen nem történt változás.

Viszont a memória úgylátszik gyorsan fogy.
Lehet ez a probléma? Mert, ha igen átdobok még 2GB-t.

top - 15:47:46 up 1 day, 5:18, 1 user, load average: 1.21, 0.66, 0.56
Tasks: 123 total, 2 running, 121 sleeping, 0 stopped, 0 zombie
Cpu(s): 17.4%us, 24.9%sy, 0.0%ni, 37.7%id, 9.5%wa, 4.4%hi, 6.1%si, 0.0%st
Mem: 1009972k total, 995452k used, 14520k free, 328968k buffers
Swap: 2618552k total, 26764k used, 2591788k free, 371932k cached

van ott még bőven mem.
ezek a tcp értékek csak régi kernelnél érdekesek, az újakban szokott működni a tcp autotuning. én is sokat játszottam vele régen, de sokat nem számítanak. egy 256k bufferrel már ki lehet hozni a maximumot, a 16 mega az enyhén felesleges :)

----------------------------------
feel the beat - it's everywhere!

Megvan a képlet

A te esetedben:
Ablak max mérete: 262144
Fejléc adatok miatti plusz költség: ablakméret/2^tcp_adv_win_scale => 262144 / 2^2 => 65536
Hasznos adat: 262144 - 65536 = 196608
GbE RTT: 5ms => 0.005s
Átvitt adat: 196608 / 0.005 = 39.321.600byte/s
Ez megegyezik azzal amit mérsz

ui:
http://www.acc.umu.se/~maswan/linux-netperf.txt

Beállítottam ezeket is. Javult 37-40MiB/sec-re...

Elolvastam a két belinkelt oldalt, de nem vagyok beljebb.
Az angolom se tökéletes és a linux tudásom se. :)

Mit kellett volna levonnom belőlük?

Ja és érdemes lenne betenni még RAM-ot? Elég csúnyán elfogy, ha másolok.

"Mit kellett volna levonnom belőlük?"

én ezt úgy kezeltem mint tuning azaz alapbeállításban megy ahogy megy, közel egyformán minden rendszeren, de lehet optimalizálni (akár a benzines autó tuning esetén) és ezzel plusszokat kiszedni. Persze én pár százalékra gondoltam, ha itt több 10 %-ról lehet beszélni akkor a büdös mindenit! Miért nincs ez jobban kihangsúlyozva mondjuk a kernel fordításakor? Mondjuk hasonlóan mint az ütemező esetén?

Na mind1 én azzal a pár megabyte növekedéssel elégedett lennék mert egy ilyen "tuning"-tól nem is várnék többet. A samba az meg nagyon érdekes dolog. Tehát ha ftp-n megvan a sebesség akkor ott nem tcp tuning a baj, hanem maga a samba, vagy a cliense!

( gabrielakos v | 2009. 07. 09., cs – 16:26 )

Ezekkel az alaplapokkal sose fogod tudni kihajtani a gigabitet.
A 32 bites pci eszkozokkel (DGI-528T asszem az) megintcsak nem.
Mert ugye annak az elmeleti max a 133MByte/sec, namost ha ezen ketszer megy at az adat (network-on be, diszkre ki) akkor mindjart felezd el, ez az elmeleti maximumod.

--
Gabriel Akos

Bedobtam +2GB memóriát így van 3GB.
A torrenteket elfelejtettem rendesen leállítani így bekapcsolás után vadul ellenőrizgette őket és a load 5-7 körül volt + a torrenflux már maga megette a memória felét.
Elindítottam egymás után több másolást is és mind 60MiB/s-ról indúlt, majd másodpercenként csökkent 1 tizedet a sebesség, amíg el nem érte a 25-27MiB/-s-t.
Putty-n keresztül figyeltem a top paranccsal és még a 3GB RAM is durván elfogyott.
Mem: 3080456k total, 3066356k used, 14100k free, 791140k buffers
Megbízható értékeket mér egyeltalán? Webmin például pont fordítva mutatja, mintha felcserélné a használtat a szabaddal..

Miután a torrentflux lecsekkolt mindent a load visszaállt 0,1-0,4 közé és a memória is szinte teljesen felszabadult.
Elindítottam újabb pár másolást, de ígyis elfogyott a memória és a sebesség most már megint 35 körül volt végig, mikor több memória volt szabad, mint az előbb...

Ahhoz, hogy még többet pakoljak bele már lassan 64bites rendszer kéne és a kliensgépet se akarom kifosztani a RAMokból, de van össz 9GB, azokat 4-5 arányban eloszhatom.
Hamár újrateszem, akkor az Ubuntu Server vagy a Debian lenne jó 64bites rendszernek? HA Debian, akkor melyik ISO-t töltsem le? CD1?
Mivel az Ubuntu a Debianra épül így olyan sok különbség csak nem lehet, de csak feltételezem.
Az apache és PHP remélem nem bugzanak 64biten... MYSQL-ről tudom csak, hogy biztosan fut 64biten.

Egyébként nem lehet, hogy a buffer vagy a sysctl beállítások túl nagyok? Eleszi a sok RAMot feleslegesen?

Mivel itt csak RAID1 van, az is csak 2 winyót érint a 4-ből és szoftveres is így nem kell, hogy a rendszer 100 vagy 200 MiB/s-re legyen optimalizálva, mert annyi úgy se lesz, hacsak valaki nem dob emg 4db 1 vagy 2 terás winyóval, meg egy RAID vezérlővel.

hol fogyna már el a memóriád???
nézd már meg, van 790 mega buffer, és van a topban még egy sor, a swapnál, ott is néz meg a cached értéket. alapból a teljes memóriát ki fogja használni (előbb-utóbb) file cache-nek, de ez nem "foglalt" memória, ha kell valaminek a ram, akkor kihagyít a cache-ből és kész, használja.

Mem: 1026868k total, 1010936k used, 15932k free, 20324k buffers
Swap: 1052248k total, 39984k used, 1012264k free, 492672k cached

a sok buffered meg azért van, mert az a 16 mega, amit beállítottál (fentebb írta valaki) max. tcp read/write buffernek, az kapcsolatonként értendő, és a torrentflux meg akár megynit neked 50-100 kapcsolatot is párhuzamosan, minden kapcsolathoz két 16 megás bufferrel... nem csoda, hogy elzabálja azt a 790 megát... ráadásul ezek az értékek felülbírálhatóak, lásd pl. sambánál SO_SENDBUF, SO_RCVBUF. hiába adsz meg sysctl-ben akármennyit, a samba akkor is annyival fog dolgozni, mint amit a SO_XXXBUF-ban mondasz neki.
de ezt már írtam fent is, a 16 mega max tcp buffer teljesen felesleges. próbáld ki, indulj el max 8k-s buffertől, és mérj egy sebességet. aztán emeld a buffert 16-ra, majd 24, 32, 64, satöbbi. egy idő után el fogod érni a maximum sebességet, és onnantól akármennyi buffert is adsz, csak a memóriát fogja foglalni de gyorsabb nem lesz. egy 128k-s bufferrel már én elértem a maximum sebességet. iperf-fel is ki tudod próbálni, mekkora window méret az optimális.

----------------------------------
feel the beat - it's everywhere!

( prygme | 2009. 07. 09., cs – 16:55 )

sajnos én is tapasztaltam a problémát, egy műholdvevőre Etherneten felmountult meghajtónál, HD adás felvételekor.

( lacika v | 2009. 07. 09., cs – 19:07 )

Ezek (smb+desktop alkatrészek) kb. ennyit tudnak. Az FTP azért lesz gyorsabb, mert kicsit egyszerűbb egy FTP kapcsolat, mint az SMB. Normális PIC-express hálókártyákkal nekem ~70MB/s jött össze. Ebben az esetben a diszk alrendszer volt nálam a szűk keresztmetszet (nem volt normális hw raid vagy külső storage).

--
http://laszlo.co.hu/

Nekem az a tapasztalatom, hogy a samba az ami ennyit tud.
Én használok samba -t egy Sun X4150-es, 8x 10kRPM SAS RAID6 tömbön, 4x1 gbit trunkolve, mégsem jön ki samba -n 22-25 MB/s-nél több.
Egyéb protokollokon (afp, nfs, ftp) keresztül megy akár 80-90 MB/sec-kel is egy-egy kliens felé.
Windows Server-ek egyébként simán kitolják a gigabitet SMB/CIFS-en keresztül, ugyhogy valoszinűsítem, hogy a Samba maga a sz@r.
Ha te samba -n el tudsz érni 70 MB/sec sebességet, akkor légyszives oszd meg velem/velünk az smb.conf -ot, illetve az egyéb beállításaidat, mert komolyan érdekel!

( hackac | 2009. 07. 09., cs – 21:57 )

Ha PCI-os a hálókari, akkor azon sose jön ki a gigabit... Ráadásul mivel gagyi alaplap van alatta, nem hiszem hogy van bekötési ábrád, és ki tudja még, mi van azon a PCI sínen.

-------------------------
E-learning szolgáltatások nyílt alapokon
Weblap és Bemutató rendszer

A teljes gigabit nem is kell, ugyanis a winyók kb 700Mbit/s tudnak maximum, de az NTFS még lejebb is viszi úgy 550Mbit/s körülre.

bsh tanácsára elkezdtem visszavenni az rmem és wmem értékekből, míg aztán 6MB-nél kötöttem ki, ami majdnem a harmada az eredetinek.
6MB után már hiába emelem nem változik semmi. A sebességet iperf-fel mértem: a linux volt a szerver csak úgy natúr és így hívtam meg a Win7ről:
iperf -c IP -w window size
Ha megvan adva window sizenak a 6MB, vagy nagyobb, akkor 80MB/s avagy 667Mbit/s a végeredmény, amivel tökéletesen meg vagyok elégedve.
De ha nem adok meg semmit, akkor gondolom a Win7 default lép pályára és 340Mbit/s a végeredmény.
Hol lehetne ezt átállítani?

A Samba SO_SNDBUF, SO_RCVBUF és max xmit is mind 6 megabájton van.
Kipróbáltam a SO_XXXLOWBUF opciókat, hogy rákényszerítsem a wint, de ettől úgy kifagyott az explorer.exe, hogy még leölni se lehetet csak elindítani még egyet. Két ""futó"" explorer.exe-nél inkább nyomtam egy resetet és kitöröltem azt a két opciót a samba configból.. :D
Eszközkezelőben találtam egy Receive buffert, ami 512 és egy Transmit buffert, ami 128. Gondolom KB, nem írja sehol, de feljebb állítani nem engedi +1-el se.

Esetleg meg lehetne erőszakolni egy NFS-sel?
Bár csak XP-hez láttam normális supportot.

Egyébként sysctl.confban beállított buffer értékek, amik 16MB-sek voltak (most már csak 6) nem a maximum értékek?
Nem feltétlen kell minden fullra kitolja... Főleg nem a 4megabites csiganethez...

Majd elfelejtettem: Miután érvénybe léptek az új buffer értékek a másolás sebessége tartotta a 45-48MiB/s-t, ami bő 10MiB/s javulás volt.
De pár másolás után megint visszaállt a megszokott a 35-re... Ugyanez volt, amikor a Windowsban megpiszkáltam a hálókártyát.
Ez a Linux vagy a Windows bohóckodása?

Passz.

Én még nem láttam olyan,h ogy valakinek rendes sebességgel ment volna a samba.
Bár mintha egyszer valaki mondta volna, hogy a szomszéd pistike egyik osztálytársának a spéci WGA-jával sikerült valahogy úgy modulálni kábelt...., de nem hiszem.

Az MS féle NFS kliens nem jó?

"Én még nem láttam olyan,h ogy valakinek rendes sebességgel ment volna a samba."

jelen. nekem "rendes" sebességgel megy. azaz megy olyan gyorsan, mintha egy picit lassabb helyi vinyóra dolgoznék, 40-60MB/s, az már nekem megfelel. nem is erőltetem a dolgot, tisztában vagyok vele, hogy nem kell csodákat várni. ez van. ha sbesség kell, akkor ftp-zek.

----------------------------------
feel the beat - it's everywhere!

nincs benne semmi extra, de tessék: smb.conf
szerverben amd athlon 64 x2 4400, 1gb ddr2-800, sima 7200-as sata2 250gb-s vinyó, semmi raid, nforce alaplap, intel pci-e 1x-es gigabites hálókártya, valami intel pro1000/pt vagy mi, ubuntu 7.04 "gyári" intel e1000e driverrel. cat5e kábelezés 3-tól 15 méterig. asus 8 portos soho gigabit switch. kliensek vista64 business, 8gb rammal, alaplapi gigabit kártyák, (broadcom, intel, realtek, van mindenféle), semmi "hekkelés" windows oldalon. illetve van egy win2000 gép, 1.6-os p4 procival, 1gb rdrammal, pci-os icplus chipes kártyával, de még azon is hozza ezt a 40-60MB/s sebességet.
ftp-n tartósan tudom hozni a 100MB/s-t is, amit a vinyó bír.

----------------------------------
feel the beat - it's everywhere!

( turul16 v | 2009. 07. 11., szo – 08:03 )

Teszt kozben egy "vmstat 2" -t tudnal mutatni ? ftp -vel es sambaval is.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( andriscom | 2009. 07. 18., szo – 12:11 )

Sziasztok!

Leírnám a tapasztalataimat mivel én is kb fél éve szívok ezzel a problémával itthon (bár ez csak a performance megszállottságom miatt van :D )
Egy sima PC-ről van szó, ne gondoljatok semmi extrára. (AMD e4850+ dual-core CPU, 2x1GB 800MHz DDR2 RAM)

1. PCI Gigabit hálókártya az tényleg PCI bus limites ahogy írták feljebb is. Szerencsére az én gagyi 12e Ft-os alaplapomon PCI-Express-en lévő integrált hálókari van, (Realtek 8111C).
2. Fontos, hogy a hálókártya chipset támogat-e valami féle CPU offloading-ot. Ilyenek szoktak lenni pl: Microsoft® NDIS5, NDIS6 Checksum Offload (IPv4, IPv6, TCP, UDP) and Segmentation Task-offload (Large send v1 and Large send v2) support.
3. Az NTFS-3G driver elég lassúcska, és főleg CPU zabáló, ráadásul nem használ csak egy magot (és nem is fog többet használni, állítólag nem párhuzamosítható).
4. Olvasásnál (a linux-os gépről) nekem is 40MB/s amit sikerült kicsikarni a samba-ból, függetlenül attól, hogy NTFS vagy ext4 particiót olvastam.
5. Írásnál (a linux-os gépre) 10-12MB/s körül mozog a samba átvitel az NTFS-3G driver (illetve a 2.4GHz-es AMD CPU limitje) miatt.
6. ext4 FS írása az jóval gyorsabb 30MB/s kb.

Két fontos észrevétel ami talán segíthet valakinek:

1. Próbáljátok ki a Paragon NTFS for Linux 7.0 drivert! Personal-use az free, a commertional license meg asszem 30$. Tudom mindenki utálja mert zárt forráskód meg nem ingyenes meg minden, ráadásul nekem fel se sikerült még rakni eddig Ubuntu 9.04 x64 alá, de ahol infót találtam róla mindenhol azt írták hogy olyan gyors mint a natív windowsos NTFS írás/olvasás.
2. Néha (talán töredezettségtől függően) nálam felment a samba átvitel 60MB/s -re (20-30 másodpercre szóval nem csak egy rövid burst volt) és ez elég bíztató mivel ez kb az én winyóimnak a határa.

Itt egy sysctl.conf (ha még nem lett volna elég belőle) :

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 524288
net.core.wmem_default = 524288
net.core.netdev_max_backlog = 2500
net.ipv4.route.flush = 1
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.ipv4.tcp_window_scaling=1
net.ipv4.tcp_timestamps=1
net.ipv4.tcp_sack=1
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_rfc1337 = 1
net.ipv4.icmp_echo_ignore_all=0

ja még annyit hogy itt egy egész jó Samba benchmark:

http://www.alternativerecursion.info/?p=48

A lényege kb:
Samba-val is el lehet érni 900-950 Mbps-et
A JumboFrame csökkenti a CPU load-ot
Szükséges lehet a klienseken (Windows gépeken) is tweakelni valamicskét
Nem mindegy hogy melyik oldal kezdeményezi az átvilet

Én átírtam a Win registry-ben azt a két Multimedia változót, sokat segített az igaz, de nem lett gigabit belőle.

Iperffel is rengeteget méricskéltem. Ha csak úgy natúr indítok egy tesztet, 340Mbit/s a max, a Samba jóesetben kb 250-300Mbit/s.
Viszont ha az iperfnek a Wines kliens oldalon megadom a window size-t és az alap helyett 6MB-t használok, akkor közel 700Mbit/s, ami kb a fizikai határ ezeken a hardvereken.
A windowsnak hogy lehet megadni, hogy ne 8kB-s window size-t használjon hanem 6MB-set?
(A Samba configban már minden jól be van lőve...)
Ezután már kiderülne, hogy a Samba bénázik-e vagy a Win7, vagy mindkettő.

Az SMB2 mikor lesz beépítve a Samba-ba is?

Már arra is adtam volna fejem, hogy NFS-t is használjak, de az meg IP cím alapján azonosít én meg felhasználó alapút szeretnék.
Meg a windows mint NFS kliens nem egy jó páros.

A Jumbo frame-hez a hálókari támogatásán kívül mi kell még?
Ha egyszer Jumbo frame lenne a szerveren attól még képes lenne az ethernetes 1500-as MTU-s klienseket is rendesen kiszolgálni?

Lassan elérkezek oda, hogy a legjobb megoldás egy WinServers+Linux páros lenne valamilyen virtualizációs környezetben és mindegyik a saját fajtáját szolgálja ki...

Az SMB ill. CIFS protokoll-nak megvannak a maga korlátai, mivel "chatty" azaz csevegős protokoll. Főleg akkor lassú, ha késleltetés van a linken. Az FTP általában némileg gyorsabb. HTTP fájlmásolás (ha megoldható) a leggyorsabb.

Ezt magyarázza meg valaki:

Ha Win7/Vista alatt kikapcsolom a TCP autotuningot, vagy experimentalra állítom, vagy vissza normalra,
akkor a legelső fájl másolás a szerverről szépen tartja az 50-60Mbyte/s sebességet. Aztán a következő már megint a megszokott 30-35...

Iperffel (Linux a szerver, Win7 a kliens), ha csak az IP címet adom meg paraméterben, akkor alapból 8kB window size-t használ és 40Mbyte/s a végeredmény, ami nagyjából megfelel a Samba átvitelnek. Véletlen lenne? De ha megadom kliens oldalról is a window size-t, pl 64kB-re, mert az már elég lenne és elvileg ennyit tud max az "alapmódban" a Win7/Vista, akkor már 75Mbyte/s a végeredmény. A Linuxon a sysctl.conf-ban a default max rmem + wmem és a smb.conf-ban a SO_RCVBUF + SO_SNDBUF is mind 64kB-re vannak állítva. (Természetesen byte-ban (65536).) De ettől függetlenül a Win7 8kB-t akar és annyit is kap. Legalábbis szerintem.

Lehet, hogy valamit benéztem, de ha nem, akkor, hogy lehetne a Win7-ben belőni egy normális fix window size-t?

A PCI-os hálókarit visszaraktam a Linuxos gépbe mint másodlagos kari.
Tervezem, hogy DHCP és DNS szerver is lesz a router helyett és akkor a WLANnak tökéletes lesz a PCI-os kártya is.

A lényeg, hogy az alaplapi gigabites, integrált kártyák mégse olyan rosszak. Sőt nagyon is jók.
A PCI-os kártya csak driverrel működött és úgy az alap 8kB-s window size-zal iperffel kb 340Mbit/s az eredmény.
Ugyanígy 340Mbit/s az alaplapi is ha fel van rakva a drivere, de ha leszedem a driverét és a Win7 alap SMB2.0 kezeli, akkor már a 8kB-s window size-zal is kb 560Mbit/s.
Ha feltolom a window size 64kB-re, akkor már 912 Mbit/s! Na ez már gigabit! :)

Szóval a kérdés továbbra is az, hogy a Win7 window size-t, hogy a rák fenébe lehet kitolni az elvileg alap 64kB-re és megszabadulni a 8kB-stől?

Ha még így se lesz jó, akkor az már csak a Samba lehet. Mikor lesz abban is SMB2.0?

egyrészt te valamit nagyon nem értesz ezen az iperfen :)
másrészt meg miért csak úgy találomra összevissza "válaszolgatsz" az éppen szemed elé kerülő postokra? ez a hozzászólásod pl. mennyiben volt válasz az "up"-ra?

----------------------------------
feel the beat - it's everywhere!

( hnsz2002 v | 2009. 07. 21., k – 19:36 )

Nemrég én is csináltam ilyet... 


[global]
        log level = 1
        workgroup = EZMOSTMINDEGY
        server string = Storage
        netbios name = Storage
        case sensitive = no
        security = share
        read raw = no
        write raw = no
        max xmit = 65536
        read size = 65536
        socket options = TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT
SO_SNDBUF=65535 SO_RCVBUF=32768

[raid]
        comment = Megosztás
        browseable = true
        null passwords = true
        path = /home/raid
        read only = No
        guest ok = Yes
        create mask = 775

A szerver valami dell desktop gép, talán 2,6Ghz-es c2d procival, 2GB rammal. A megosztott könyvtár hardveres raid5 egy 3ware kártyán, 3db 7200-as sastas samsung diszkkel. NIC: Broadcom Nextreme pci-e gigabit ethernet, os: opensuse 11.1 x64.
Kliens 1:
az én asztali gépem (szintén suse 11.1 x64), RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02), c2d e8400, 4GB ram, és amire másoltam partíció, az szoftveres raid0 két 7200-as satás samsung hdd-n.
iperf 947Mbitet mért, FTP 102MB/s (megabájt!), NFS 60MB/s, samba 39MB/s volt.
Kliens 2:
valami dell, win7rc os-sel, p4 2ghz, 2gb ram, 1db samsung 7200-as diszk, szintén broadcom nextreme pci-e gigabit ethernet. FTP 103MB/s, samba 103MB/s...
szerk.: jah, full cat5e kábel, semmi cat6.
--
Discover It - Have a lot of fun!

( andriscom | 2009. 08. 03., h – 12:59 )

Rég nem érkezett hozzászólás... akkor most mi a helyzet ezzel?

Nekem is sikerült iperf-el 970Mbit-et mérni 64k window size-al, de hogyan lehet beállítani a Windows 7-nek (tehát a kliens oldalon) hogy 64k-t használjon window size-nak a samba?

Vagy csak simán annyi a megoldás, hogy használjunk Samba 4-et a Linux (szerver) oldalon mert az támogatja az SMB2.0-át és ennyi? (Jelenleg alpha8-nál tart a Samba4!)

Hát nem tudom, és Mac-ekkel használok samba-t, és úgy jönnek ilyen gyászos számok (22-25 Mb/sec, szerver rendes vas, 4gbit trunkolve, 8x10k rpm SAS lemez RAID6-ban, rendes switch, kliensek gigabiten, stb.stb.)
Samba-n kívül minden fájlátviteli protokoll kitolja a gigabitet.
Sajnos a Sambaval lehet normálisan szabályozni a hozzáféréseket, ezért nálunk szükséges. :(
De az ilyen public megosztások, meg ilyenek, afp-n menek.

Hát nem tudom, és Mac-ekkel használok samba-t, és úgy jönnek ilyen gyászos számok (22-25 Mb/sec, szerver rendes vas, 4gbit trunkolve, 8x10k rpm SAS lemez RAID6-ban, rendes switch, kliensek gigabiten, stb.stb.)
Samba-n kívül minden fájlátviteli protokoll kitolja a gigabitet.
Sajnos a Sambaval lehet normálisan szabályozni a hozzáféréseket, ezért nálunk szükséges. :(
De az ilyen public megosztások, meg ilyenek, afp-n menek.

( Lightning | 2009. 09. 19., szo – 11:00 )

Na végül sikerült feltornásznom a megcélzott sebességre a dolgokat. :)
Annyit foglalkoztam már régebben a Samba configgal, hogy szerintem minden létező tuning opció ki van már aknázva.
De szívendöfésként NTFS partíciók voltak a RAID1 tömbökben, mert még nem volt 100%, hogy marad a Linux a szerveren.
Nos lecseréltem ext3-ra a partíciókat. Még szerencse, hogy RAID1 volt mind, így nem kellett konvertálni se,
hanem csak az egyik lemezt újra formázni ex3-ra és átmásolni a másikat, majd újraszinkronizálni a tömböt.

A lényeg, hogy így most már kisebb fájloknál is stabilan tartja az 50-60 Mbytes/s sebességet.
Nagyobbaknál néha, eléri a 70-80Mbytes/s sebességet is. :)
Egyszer írt 100-120Mbájt/s-t is, de szerintem itt csak elszámolta megát, mert szoftveres SATAII RAID1 nem ilyen gyors...

Azért van humora a linuxnak. :D

( JoHn123 v | 2009. 09. 19., szo – 12:52 )

Örülök hogy sikerült.
Esetleg a jól működő konfigodat nem tennéd közkinccsé?

Természetesen. De alig ha változott a topic elején levőtől:
Az hiányzott nagyon, hogy ext3 legyen minden megosztott partíció. Nem is tudom mért használtam még mindig NTFS-t. :)

Szerk.: A swap eltüntetése is mintha segítene. Elvégre ha csak RAM-ra írhat és van elég, nem lassítja be a HDD.

[global]
netbios name = server
server string = HomeServer
workgroup = WORKGROUP
wins support = true
name resolve order = wins lmhosts hosts bcast
allow hosts = 127.0.0.1 192.168.0.0/255.255.0.0
deny hosts = 0.0.0.0/0
socket options = SO_KEEPALIVE TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT SO_SNDBUF=65536 SO_RCVBUF=65536
max xmit = 65535
dead time = 15
read raw = yes
write raw = yes
getwd cache = yes
oplocks = yes

passdb backend = tdbsam
obey pam restrictions = yes
pam password change = no
encrypt passwords = true
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
panic action = /usr/share/samba/panic-action %d

guest ok = no
map to guest = bad user
homehare allow guests = no

path = /mnt
default = global
local master = yes
log file = /var/log/samba/log.%m
max log size = 1000
debug level = 1
os level = 20
syslog = 0

valid users = @slaves,@masters
read list = @slaves
write list = @masters

vfs object = recycle
recycle:keeptree = Yes
recycle:touch = Yes
recycle:versions = Yes
recycle:maxsize = 0
recycle:exclude = *.tmp *.temp *.o *.obj ~$* *.~?? *.*~ *.$$$ *.bak

[printers]
comment = All Printers
browseable = no
path = /var/spool/samba
printable = yes
guest ok = no
read only = yes
create mask = 0700

[print$]
comment = Printer Drivers
path = /var/lib/samba/printers
browseable = yes
read only = yes
guest ok = no

[Share1]
path = /mnt/Share1
recycle:repository = /mnt/Share1/.recycle

Nyugi nálam se megy gigabittel se ext3 se ext4 se JFS se NTFS fájlrendszerrel.
Oké az NTFS amúgy is bukta mivel az NTFS-3G driver megeszi a procit, bár elvileg a fizetős NTFS-3G amit a Tuxera forgalmaz az sokkal gyorsabb:
http://www.tuxera.com/products/tuxera-ntfs-commercial/performance/

Na de a lényeg, hogy jó hir is van: A Samba 3.5.0pre1-ben (November 26, 2009) megjelent az SMB2.0 támogatás!!! :)
igy kell engedélyezni a konfig fájlban: "max protocol = smb2"

A Samba levlistán azt irták, hogy a Samba 3.6-ban lesz először defaultban engedélyezve a SMB2.0, ami várhatólag nyáron (2010 júniusában) jön.

Ja és találtam valahol egy prezentációt is amiben azt bizonygatták a Samba fejlesztői, hogy felesleges a SMB2.0 mert valami iszonyatos 700MB/s-et el tudtak érni az alap SMB protokollal is. A lényeg, hogy a klienes jól legyen optimalizálva... nah persze ezzel nem sokra megyek ha Windows gép a kliens oldal.

Az abszolút gigabittől mindenki messze van. :)
700MB, mint Mbyte? Az több, mint 5Gbit, ami gondolom 10G-s hálon lett tesztelve, így már nem is olyan jó. :)

Jó hír, hogy már a 3.6-ban lesz SMB2, azt hittem csak a 4-ben, ami még nagyon alpha.
A pre 3.5-ben fogadni mernék, hogy egyeseknél még lassabb vagy bugosabb lesz. :)

Ja, persze, a kliens legyen optimalizálva... LOL :-) A trombita meg fújja a rezesbandit, mi? Gondolom SaMBa szerver meg smbclient hasít együtt, mintállat :-)) de ha tetszőleges Wines alkalmazást veszek, akkor vagy megy, vagy nem, vagy "épphpgycsak" működik. Nálam ez utóbbi volt, ergo a samba kiesett a pixisből, 23- napos kísérletezgetés után. (Az alkalmazás rendelkezésre áll, neki lehet állni kitökölni, hogy miért lassú, és hogy mivel lehetne gyorsítani -- egy megkötés van: az alkalmazás módosítása nélkül...)

Szerintem most már nyugodtan kijelenthetjük, hogy ahol Windózos kliensek vannak ott _szinte_ mindig Vista/Win7 van, amik elég jók a kliens oldali hálózat kezelésben.
Jó néhány dolgot ki kell baltázni belőle, pl a multimédiás akármit, de utána jó.
Nekem pl ugyanoylan gyors Win7-ről, mint egy Linuxról SMBclienttel...

Lósz@rt, mama! Ahol 2-3 éve vettek gépet, ott XP volt, van -- és lesz is még egy jó ideig. Lehet, hogy sima fájltranszfer esetén hasít, de azt nem kunszt megcsinálni, itt arról van szó, hogy alkalmazás nyitja/zárja a fájlokat, amibe a samba gyakorlatilag belerokkan, azaz alkalmatlan az adott feladat ellátására.

Van mondjuk 15 gép. Ezeken OEM XP van, amit jórészt az utóbbi 2-3 évben vásároltak, részben géppel együtt. Az alkalmazásaik működnek (pénztár, főkönyv, iskolai nyilvántartó rendszer, oktató- és tesztprogramok, levelezés, stb.) Akkor mi a francért dobnának ki ismét 3-500E Ft-ot csak szoftverre (a hardverbővítésről, illetve a migrálás munkadíjáról, az új rendszerre való átszoktatás (oktatás, problémák kezelése, támogatás) felmerülő plusz költségeiről, valamint a kieső munkaidőből adódó veszteségről nem is beszélve)? Semmiért. Nincs jól védhető gazdasági indoka a váltásnak -- ha majd megdöglik egy vagy több gép, akkor az újakra vagy a meglévő néhány "dobozos" (gépek között mozgatható) XP, vagy pedig az akkor aktuálisan kapható cucc kerül -- és szép lassan "kihal" a régi szoftverkörnyezet.

Én sem értem... Sajnos még rengetegen. El kéne már felejteni nagyon.
Talán mert a programozók jó része lusta, én nem hajlandó megtanulni és úgy megírni a programot, hogy az fusson újabb rendszereken. Pl. soros portot közvetlenül írja/olvassa, program files-ba írkál mentéseket meg temp fileokat, stb.
Úgy, ahogy a mai napig vannak még DOS-os programok is, úgy XP is lesz még kb. 15 évig.
--
Discover It - Have a lot of fun!

Egyszerű oka van. Nagyban olcsóbb üzemeltetni, mint átállni egy Vistára/Win7-re.
Enterprise környezetben rengeteg 3rd party szoftver van, ami nem megy, nincs tesztelve az új Wineken és az átállás költségét/kockázatát magasnak tartja a vezetés. Több százezres kliensoldali gépparkkal rendelkező cégeknél pont emiatt a mai napig pl. XP van és nem Vista. Majd átállnak, ha nem lesz security fix sem az XP-hez.