- A soknál is több pénzzel gyorsítaná fel a hazai chipszektort Kína
- TCL LCD és LED TV-k
- Mikrokontrollerek Arduino környezetben (programozás, építés, tippek)
- Milyen billentyűzetet vegyek?
- Mini-ITX
- Hobby elektronika
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- AMD Navi Radeon™ RX 6xxx sorozat
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- iPad topik
Hirdetés
-
F1 24 - Íme a végső gépigény
gp Akik a Champions Editiont vásárolták meg azok már játszhatnak a programmal.
-
Tényleg három színben érkezett a Nothing Phone (2a)
ma Csak mindhárom ugyanazon a hátlapon csoportosul, az új, limitált kiadású Phone (2a) megjelenése így még mozgalmasabb lett.
-
A soknál is több pénzzel gyorsítaná fel a hazai chipszektort Kína
ph A China Integrated Circuit Industry nevű befektetési alap elsődlegesen a chipgyártáshoz szükséges berendezésekre fókuszálhat.
Új hozzászólás Aktív témák
-
sTERNI
senior tag
Tesztet kérünk szépen (majd)
Sok helyen olvastam már ilyen kütyüről, nem egy embernek jutott eszébe ilyesmi; de, ha beválik és a licenszekkel sem lesz nagy probléma... akkor szerintem hamar el fog terjedni, idővel pedig valami beépített (routerbe, hálózati csatolókba) verziót is el tudnék képzelni."You travel with fascinating companions, Doctor."
-
orbano
félisten
Aztán majd a tré-online ezt is betiltja, és a linksys weboldalát majd nem lehet elérni sem... kíváncsi vagyok, letöltés közben mennyi lenne egy ilyenne la pingem.
Egy másik kérdés pedig: ha ezt bekötöm mondjuk a gépem és a wifi access point közé, akkor elérhetem vele, hogy prioritást kapjak aznon a hálózaton, amire csatlakozok és ahonnan a netet is kapom?A vér nem válik VAZZE!™
-
VladimirR
nagyúr
ne beszelj mar fas....ooo....butasagokat, miert tiltana be?
tudom, most jon az, hogy ''de bezzeg a cfos....'' - egen, par orat le volt tiltva, mert csak annyi latszott, hogy egy ip-re nagyon nagy forgalom megy, dos-nak veltek, levagtak
miutan kiderult, levettek a tiltast, azota egy parc kihagyas nem volt
azt aruld mar el, miert kell mindenbe belekeverni az esz nelkuli fikazast? nem volt gyerekszobad?
a kerdesed nem teljesen tiszta, de nem te kapsz prioritast, hanem bizonyos csomagtipusok - letolteni nem fogsz gyorsabban, de a game, es a a/v atvitel (elvileg) nem fog akadozni
engem inkabb az erdekelne, hogy mi alapjan ad ez kisebb/nagyobb prioritast a csmagoknak? port alapjan? -
bambano
titán
Gondolom a cikk egy az egyben átvett valami marketing anyagot, mert amit ide írt, az önmagában is ellentmondásos. Ha a nagyméretű letöltések melletti voipozáson akar segíteni azzal, hogy a forráshoz közel vizsgálja a forgalmat, akkor az nem az előfizetői adsl modemnél van, hanem ott, ahol a letöltés szervere van, esetleg az adsl carrier szolgáltató forgalomátadási routerében. A kimenő forgalom szabályozásának elvben lenne értelme, de egyrészt az nem a letöltéskor számít, másrészt azt ténylegesen a forrásnál, vagyis a pc-n futó oprendszerben kell/érdemes csinálni. Ennek az eszköznek a hasznossága szerintem egyenlő a dvd visszacsévélő gép hasznosságával.
A linksysnek meg további gondolkodásmentes jónapot kívánok.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
janpotocki
senior tag
nincs ebben ellentmondás, hiszen a voip (váltakozó irányú adatforgalom) egyik forrása a felhasználónál van, és ott előnyt biztosít neki ez a szerkezet a letöltéssel szemben. tény, hogy az interneten még bármi megeshet a voip csomagokkal, de a felhasználó oldalán legalább rendben vannak. a voip-es pc-n hiába priorizálod a forgalmat, ha a letöltés egy másik gépen megy, és a router nem ismer qos-t.
-
VladimirR
nagyúr
válasz janpotocki #5 üzenetére
szerintem arra celzott bambano, hogy ha vesz a user egy ilyet, attol neki nem lesz jobb
a beszelgetopartnerenek, aki az o bamba kepet bamulja a neten keresztul, annak igen, de a mi user-unknek nem (hacsak nincs a masik felnel is egy ilyen ketyere) -
bambano
titán
válasz janpotocki #5 üzenetére
A letöltés a világból befelé, a gép felé jön és relatíve kevés ráhatással tudsz lenni. A letöltésnek az a része, amelyik kifelé megy, elenyésző méretű csomagokból áll. Ha elkezdel letölteni egy nagy állományt, akkor a kifelé menő irányban nincs torlódás, azon nincs mit szabályozni.
De ez természetesen csak a webes vagy ftp-s letöltésre igaz. Ha olyan hálózatot használsz, ahol a policy az, hogy neked is szolgáltatnod kell (köteles vagy te is megosztani, vagy a te géped is feeder lesz, mint pl. bittorent), akkor elvben lehet komoly kimenő forgalmat generálni. De minek veszel dobozt azon forgalom megregulázására, amit a bittorent kliensben egyébként is lehet korlátozni? Az mennyire életszerű feltételezés, hogy valaki profin voipol, letölt ezerrel és nincs ráhatása a gépekre?
Tehát ez a dobozka továbbra is a spanyolviasz kategória.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
A beszélgető partnernek se lesz jobb. A nagy állományok letöltése legrosszabb esetben is 9-10x annyi bejövő forgalmat generál, mint kimenőt. Tehát egy 768/256-os adsl-en csinál 768 bejövő és kb. 80 kbit/sec kimenő forgalmat. Ráadásul a kimenő csomagok rendszerint kicsik, csak tcp ack és hasonlók vannak benne. A 256-os sávszélesséből még marad 150-160 kilobit/sec üresen, a késleltetés se változik nagyon 80-100 byetos csomagok miatt. Egy majdnem üres dróton mit variál ez a doboz?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
janpotocki
senior tag
érteni vélem, de ha feltesszük, hogy a túloldalon minden rendben és az internet sem fogja meg a voip-csomagokat, akkor marad hibalehetőségként a saját lan, és ezen segít ez az eszköz. azt, hogy priorizálni a forrásnál célszerű, általános elvként írtam.
egyébként könnyen elbeszélhetünk egymás mellett, hiszen nem tudni pontosan, mi lakik a belsejében, egy egyszerű sávszélesség-menedzsment, vagy vmi komolyabb qos mechanizmus (azaz, hogy jelöli-e vmi módon a kimenő csomagokat, vagy csak magának állít fel egy fontossági sorrendet, illetve ha az előbbi, mi az esély rá, hogy a szolgáltató nem bírálja ezt felül csípőből) -
janpotocki
senior tag
miért ne tudnék hatással lenni a befelé jövő forgalomra? azt mondom például, hogy csak x sávszélességet kap, de csak akkor, ha nem gátolja a bármilyen irányú voip-forgalmat. ez esetben csökkentem a sávszélt, vagy ha van alkalmas eszközöm ideiglenesen várakoztatom a csomagjait, hiszen letöltésnél mindegy, mekkora a késleltetés/jitter
-
VladimirR
nagyúr
kishazankban a nagy sebessegu letoltes mell altalaban feltoltes is jar, es nem csak ack csomagok kepeben, mivel eleg nepszeruek a filemegoszto programok
szoval tobbnyire van ott kimeno forgalom, es ekkor igenis hasznos a qos
en cfosspeed-et hasznalok, elegge meg vagyok elegedve, nelkule nem igazan volt hasznalhato a net, ha beingitottam a dc-t -
bambano
titán
válasz janpotocki #9 üzenetére
Úgy érted, hogy a 100 megás saját lan késleltetni fogja azt a forgalmat, ami bejött a néhány megabites adsl-en vagy csellón?
Tökéletesen igazad van abban, hogy priorizálni a forrásnál célszerű, ezt én még megtoldanám azzal a kitétellel, hogy akkor, ha szűkös, túlterhelt a sávszélesség. A letöltésnél a sávszélesség lehet szűkös, de annak a forrása a világvégén van, sőt, a letöltés és a voip forrása nem is feltétlenül egy helyen. Az első közös pont, ahol a két forgalom biztosan találkozik és reális esélye lenne a qos-nak vagy a korlátozásnak, az az ISP és az adsl carrier szolgáltató routerei közötti link (az ''adsl carrier szolgáltatás átadás-átvételi pontja''). Erre tudtommal nincs ráhatásod.
A kifelé menő forgalom forrását pedig el tudod kapni, mert az lakáson belül van, erre viszont a fenti példa alapján nem érvényes a szűkösség kitétel.
A szolgáltató szerintem nem foglalkozik azzal, hogy milyen kimenő forgalmad van, biztosan nem fogja csereberélni a csomagok sorrendjét, hanem ami felcsorgott tőled 256k-val, azt ő a sok tíz vagy száz vagy gigás gerincén villámgyorsan kitolja a világba.
Még mindig nem látom értelmét annak, hogy a kifelé menő irányon van ilyen egy csomag-nagy szünet-egy csomag-nagy szünet jellegű forgalom, azon mit kell macerálni drága dobozzal.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
csiga997
őstag
Konkrétan senkinek nem lesz jobb, amíg nincs end-to-end diffserv támogatás a távoli szerver és a kliens között, vagy RSVP, ami méginkább nincs.
A csomag priorizálását az adatfolyam forrása képes megtenni, tehát az uplinket lehet befolyásolni. A letöltés helyén maximum a nagyforgalmú adatfolyam blokkolásával lehet sávszélességet felszabadítani (pl. delayed TCP acknowledge-ekkel lassítani a letöltést) de lényegében ez is az uplink forgalomba való beavatkozást jelent. Ha a szerver és a kliens végpont közötti downstream szolgáltatók (az összes!) nem támogatják az eltérő forgalmi osztályok szerinti csomagütemezést akkor a végén minden ugyanabba a traffic-classba fog tartozni, amit a szolgáltató szépen beönt ugyanabba a csőbe azt lesz ami lesz. -
bambano
titán
válasz janpotocki #10 üzenetére
Mert a te bejövő forgalmadra csak az adsl modem után van hatásköröd. Annak meg sok értelme nincs, hogy bejön egy-két megabiten egy forgalom, amely drót konfigurálására nincs lehetőséget, majd utána kezdj el sávszélességet macerálni, amikor a két megabit átkerül a 100 megás helyi hálózatra.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
csiga997
őstag
válasz janpotocki #10 üzenetére
A befelé jövő forgalomra semmi hatásod nincs, csak az általad generált forgalmat tudod korlátozni és szabályozni. A befelé jövő forgalmat, ha már egyszer az ISP oldalán letorlódott, akkor a te eszközödben csak legfeljebb még jobban meg tudod nyomorgatni, pl azzal, hogy eldobálod a nagy nehezen beérkezett csomagokat vagy pedig nem küldesz acknoweldge-et a beérkezett csomagokra és a forrás majd valamikor később újraküldi. De ezzel nem nyersz plusz sávszélességet a ''fontos'' voip és egyéb forgalmad számára, mert azt a szűk keresztmetszet elején, vagyis az adsl/cable linked másik végén azaz az ISP oldalán az ISP-nek kéne külön forgalmi osztályok és prioritások szerint kezelnie. A mai ISP viszont ilyet nem csinál.
-
bambano
titán
Ahhoz, hogy a doboz delayed ack-ot tudjon, értelmeznie kellene a teljes adatfolyamot. Ehhez ki kellene csomagolnia a ppp over ethernetet, azon belül az összes gép összes tcp kapcsolatát nyomon kellene követnie és minden tcp sessionra külön meg kellene ezt csinálni, majd az egyészet újra összerakni. Nem tudom fejből, hogy a ppp protokoll szükségképpen sorrendtartó protokoll-e, ennek utána kellene nézni, mert ha igen, akkor ez nem működik.
Ha leküzdöm a szkepticizmusomat, hogy egy kis dobozkában fillérekért mindezt megéri megcsinálni, akkor tudom mondani, hogy igazad van és érdemes ilyenbe beruházni. Egyéb esetben csak azt tudom mondani, hogy igazad van, spanyolviasz feltalálás esetét láttukEgy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
-
janpotocki
senior tag
most már kezdem magam kínosan érezni, mert nem akarom védelmembe venni ezt az eszközt, de nem sikerült felfognom azt sem, miért ne lenne abszolút semmi értelme. igaz, a bejövő forgalomra csak a modem után van hatásköröm. legegyszerűbb, ha szoftveresen, a pc-n megfogom, ha épp nem érdekem, hogy mind a 2 megabitet kitöltse. de teszem azt, hozzá nem értő felhasználó vagyok, vagy az öcsém bosszújának esem áldozatul, aki pofonmentesen lezárt szobájában bittorentezik etc. ilyenkor jó esetben átszabom a sávszélességét a routerben, de ha erre nincs mód, beteszek egy efféle eszközt. ha jól működik (nem tudom, ez konkrétan hogyan működik), és tudja, hogy nekem a voip-hoz mindkét irányban szükségem van x sávszélre, akkor időnként csomageldobálással megfoghatná a bejövő forgalmat is, így egy idő után (a windowing miatt) a szerver eleve lassabban öntené az adatokat. és ez az egész a 2 megabitről szól, utána a 100 megabites lanon már senkit nem érdekel, hogyan mennek az adatok, van helyük. nem?
-
kraftxld
nagyúr
Magyarul ez egy sima QoS adapter?
| MCSE+M/S, MCITP, VCP6.5-DCV - ''Life can be hard, but Scooter is harder :)'
-
VladimirR
nagyúr
válasz janpotocki #9 üzenetére
egen, ebbe akkor lehetne belemenni, ha tudnank, mi is van az eszkozben, es mire kepes
-
csiga997
őstag
Egy ideális világban ugye elég lenne csak a DSCP mezőt kiolvasni az IP fejlécből, de ugye ez nem egy ideális világ...
Kicsit butább módon elég lehet, ha a tcp/udp portszámokból ''felismeri'' a high-priority forgalmat, minden más pedig best effort és lehet sanyargatni. Ez viszont erőforrás-igényes.
A PPP L2 protokoll és annyiban sorrendtartó, hogy soros vonalon nem szokás egymást előzgetni a csomagoknak. Viszont az IP szinten már lehet OOP ami nem lenne szabad, hogy gondot okozzon, mivel az IP connectionless protokoll. Persze, a felsőbb layereken ez már okozhat gondot, és tipikusan a voip ilyen, ami nem szereti, ha beelőzgetik egymást a csomagok. De lehet pl. selective discard-ot is csinálni a best-effort forgalomra, igaz, ezzel jól megszivatja csak magát az ember, viszont a szkájpin rezzenéstelen lesz a kép amíg a letöltés a háttérben 2x annyi ideig tart majd. Dehát valamit valamiért, ugye.
[Szerkesztve] -
bambano
titán
válasz janpotocki #20 üzenetére
Arról szól ez a thread, hogy a befelé jövő forgalmat nem tudod szabályozni, nem csak ezzel az eszközzel hanem mással sem. Ez a dobozka a kifelé menő forgalmadat szabályozza. Itt a befelé jövő forgalom alatt nem azt kell érteni, hogy letöltés vagy webezés, hanem ip/ethernet csomagok szintjén a nyers forgalmat.
Ha elindítasz egy letöltést, az az egy darab letöltés, ami gyakorlatilag arról szól, hogy kintről, világvégéről bejön hozzád egy állomány, egyszerre generál bejövő és kimenő forgalmat is. Jön be az anyag, kisebb adagokra bontva, a te géped időnként szól a szervernek, hogy az eddigieket rendben megkapta, küldje a következőt. Ezen két forgalom aránya 1:10 vagy még rosszabb, vagyis egységnyi kimenő forgalomra legalább 10 egység bejövő forgalom jut.
Ha a szolgáltatód már beletolta abba az atm pvc-be a csomagot, ami neked szól, azzal te már semmit nem tudsz csinálni, mivel a szűk keresztmetszet a szolgáltatódtól az adsl modemedig terjedő drót. Ha már átjött az anyag a szűk keresztmetszeten, azt már kevéssé értelmes tovább babrálni.
Ha az öcséd kekeckedik veled és te hozzáférsz a routerhez, hogy rádugj egy ilyen dobozkát, akkor sokkal olcsóbb megoldás kihúzni a routerbe integrált switchből az öcséd ethernet drótját és hidd el, mindjárt megjavul a tárgyalási kézsége.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
-
VladimirR
nagyúr
ne, fokent, hogy ezt a szoftveres megoldast megkaptam 3k-ert
de van, akinek ez nem megfelelo, mert mint janpotocki is irta, elofordulhat, hogy tobb gep van a ''haztartasban'' (irodaban, kinek mi), es ezesetben nem mukodik a szoftveres megoldas
mondjuk en ezesetben is inkabb osszedobnek egy p1-est routernek, ra meg valami kimondottan ilyen celra keszult os-t (pl a coyote linux nekem tetszett anno, mikor hasznaltam, es qos is van benne - legalabbis asszem a coyote volt az) -
janpotocki
senior tag
ok, ez mind világos, nyilván nem arra gondoltam, hogy a már dróton lévő adatok beömlését szabályoznám. de a csomageldobálás nagyon is hatékony megoldás lehet, mert (záros idő után) eleve kevesebb adat kerül a drótra. felemás, buhera megoldás, főleg a diffserv és társaihoz képest, de mentőöv lehet. abba egyáltalán nem szeretnék belemenni, hogy ez dollárban kifejezve mennyit érhet
szerk.: öcsém igazából nincs, így nem sokat -
bambano
titán
Két utat látok: precízen visszafejti, hogy a dugulást melyik tcp session okozta és azt az egyet fékezi meg ack delay-jel vagy agyatlanul minden tcp sessiont megfékez ezzel. Utóbbi esetben kockáztatja azt, hogy olyan sessiont is lefékez, amit egyébként nem kellene.
A ppp sorrendtartására vonatkozó kérdésemben azt akartam kérdezni, hogy a ppp a soros dróton nem változtatja meg a csomag sorrendjét. A kérdés az, hogy a protokollhoz tartozó állapottérben ezt ki is használják-e vagy sem. Ha azt alapértelmezem, hogy a csomagok sorrendje nem változhat, akkor csinálhatok olyan protokollt, amiben ellenőrzöm pl. sorszámmal a csomagokat és ha egy kimarad, akkor azt hibaként detektálom és megvárom az újraadást. Vagyis elvileg előfordulhat, hogy a ppp protokoll úgy van definiálva, hogy ha nem sorrendben érkeznek a csomagok, akkor az hibára utal és megpróbálja visszaállítani a sorrendet. Ebben az esetben ha a dobozka felcseréli a tcp ackok sorrendjét az ack-delay miatt, akkor felborulhat a gép-adsl modem kapcsolat. Ha nem cseréli fel, akkor meg maga a dobozka okozhat voipban késleltetést.
Lehet, hogy nem sikerült jól leírnom, amit mondani akkarok, sorry. Ehhez kellene pontosan ismerni a ppp-t.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Eperfa
tag
őszintén nem értem mi a bajotok a ketyerével.
van itthon 2 gép. nálam általában bentvan vmilyen filemegosztó progi (éppen emule, de sokat nem számít), bátyám szeret játszani (az egyébként híresen szar multiplayer-kódú mohaa-val).
ahhoz, hogy ő játszani tudjon, nekem irreálisan kicsire kell korlátoznom (a saját gépemen, software-esen) a feltöltésemet (egy pár k feltöltési sebesség felett már lagol az ő játéka), ugyanakkor nyilvánvaló, hogy ennél sokkal többet is meg lehetne reálisan oldani
pont erre való ez a kis szar. a mostani linksys routeremben is van qos, és nem kell semmi egetverő dolgora gondolni, semmi csomagelemzés,s tb, egyszerűen a küldő port alapján lehet beállítani a priorityket. igen valószínűnek tartom, h ez is pont uígy működik. az egy más kérdés, h a mostani routerem alap firmware-jével egyszerre csak egy portra leeht megadni a priorityt, összesen pedig 8ra, tehát egy ezres nagyságrendű porttartományt használó játéknál keveset segít a dolog, demajd átégetem a firmware-t, rem akkor már lehet porttartományokat definiálni
szóval sztem nem kell annyira fikázni a dolgot, soho/home eszköz, és arra nagyjából megfelelő -
VladimirR
nagyúr
ezt a befele semmi beleszolasom nincs dolgot nem igazan ertem
nem ugy van (tanitottak valami ilyesmit), hogy ha nem kapja meg a kuldo az ack csomagot, akkor ujrakuldi ugyan, de ''lassabban'' (valami frame meret csokkentes remlik, de nem akarok hulyeseget mondani - be kellett volna jarni eloadasra)?
mert ha ez valoban igy van (es nem csak hulyesegeket beszelek), akkor megiscsak tudom szabalyozni a bejovo forgalmamat (megha kozvetve is, ugy, hogy a kuldo kimenojet szabalyzom...) -
bambano
titán
válasz janpotocki #28 üzenetére
Az a sejtésem, hogy ezzel tönkretennéd a voip azon elvárását, hogy a csomagok késleltetése ne legyen nagy szórású és előre megjósolható legyen.
Ha eldobsz egy csomagot, az csak a tcp window size kitöltése után fogja megállítani a feladó gépet, aki várakozni fog a tcp ack-ra, de az nem jön meg, de addigra a teljes window size mennyiségű adatot beletolta már a hálózatba. Majd időzítés lejárása után újraküldi azt az egy csomagot, mire te ezt már elfogadod. A fogadó gép tcp szoftvere pedig az egész window size-t le fogja nyugtázni, mert addigra minden adat megjött, a feladó pedig megörül, hogy minden odaért, újabb adag window size méretű adatot tol a drótba. Ami szépen ki fogja sámfázni az adsl-t. Vagyis úgy fog kinézni a nagy letöltésed, hogy minden másodpercben kb. 1/3 másodpercre kisámfázod ezerrel a drótot, ekkor a voipod recsegni fog, majd egy darabig üres lesz. (300kbyte/sec letöltési sebességgel és 128k window mérettel saccolva).Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
csiga997
őstag
...vagy pedig agyatlanul megfékez minden olyan tcp sessiont, ami nem high-priority, voip, streaming, stb.
PPP kapcsolat nélkülö protokoll, nincs semmiféle sorrend-vizsgálat. Tehát akár meg is előzhetik egymást a frame-ek, bár ez egy soros vonalon tipikusan nem jellemző. Ettől függetlenül nincs erre megkötés. -
G.I.JOE
senior tag
Micsoda káromkodás folyik itt!
-
Cs_Laci
senior tag
Fortyogás ON
Annyira imádom az Informatikát.. 25 000 problémát felvet, ami Informatika nélkül nem lenne.. Pl ha végre kitalálnának valami QoS-t nyújtani képes Transport Layer-t, akkor nyilván ilyen eszközökre nem lenne szükség.. De ezt nagyon régóta képtelenek megtenni, úgyhogy elterjedt ez a Remek Ethernet.. Ami aztán sokmindenre innentől kezdve csak erőteljes megerőszakolás után alkalmans.. Ez az eszköz egy ékes példája.. ..
Fortyogás OFF
Amúgy szoftveresen 1 gép esetén Win alatt lehet valahogy csomagoptimalizálást csinálni? -
Cs_Laci
senior tag
Az hagyján, de mi van azokkal, akik pl E-Mule t használnak?? Ott ez az arány nagyon nincs így
Szegény csacsizók mindig megszívják.
Amúgy meg az ATM szép meg jó, de az is egy megerőszkolása a technológiának, amikor te ATM-be belecsomagolsz meg kicsomagolsz pl a TCP/IP szintig. Az sem egy triviális művelet drága kapcsolókkal..... Szóval még mindig elemi szinten vannak a gondok SzvSz...
Új hozzászólás Aktív témák
- Szerkesztett és makrofotók mobillal
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Kerékpárosok, bringások ide!
- Skoda, VW, Audi, Seat topik
- Xbox Series X|S
- Google Pixel 8 Pro - mestersége(s) az intelligencia
- Honor Magic V2 - origami
- A soknál is több pénzzel gyorsítaná fel a hazai chipszektort Kína
- USB to S/PDif konverter a modern RIAA, elektroncsövekkel
- TCL LCD és LED TV-k
- További aktív témák...
- Macbook Pro M2 24/512gb Cto, garanciális, vadonatúj állapotban
- Dell Latitude 5290,12.5" ,i5-8350U,8GB DDR4,256GB SSD,WIN10
- Új Gamer PC i5 10400F/RTX 3070 8Gb/500SSD NV2 M2/2x8Gb 3200Mhz DDR4/700W Bronz 3Év gari
- Lenovo ThinkPad Workstation Dock 40A5
- Dell Latitude 7390,13.3",FHD ,i5-8350U,16GB DDR4,256GB SSD,WIN10
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs