BGAFC Vendégkönyv

Σ: 16 post

TCH (statz)

#1, Főfasz (10443)

708 | #2990 | ^ | Idézet | Thu, 26 Dec 2013 22:10:45 +01

31.46.*.*

*.catv.pool.telekom.hu

@djpety:
De ez bármelyik játékkal megtörténhet.

Hát, inkább úgy volna pontos, hogy más játékkal is megtörténhet.

@djpety:
Valószínűleg egyedi eset, és valami ütközés történt egy bizonyos verzióval.

Ezt nem tudom, mennyire egyedi eset, de a Steam-et nem ketten rühelljük ezzel a csávóval.

@djpety:
A te eseted furcsa, reklámokkal sem találkoztam még a Steamben (már ami nem Steamhez köthető, az is csak ritkán, a kliensen belül).

Ez mondjuk cca. 10 éve volt, szóval azóta sok háj lefolyt Gabe Newell-en. :P

@djpety:
Ettől még lehet egy raklapnyi fos, csak nálam pont megy.

Vulva sok okosságot csinált, nem csak a Steam-et, pl. ezt is: http://www.youtube.com/watch?v=e0WqAmuSXEQ

kemi (statz)

#2, Főfasz (2970)

343 | #2991 | ^ | Idézet | Thu, 26 Dec 2013 22:21:47 +01

94.21.*.*

*.pool.digikabel.hu

Nekem is van pár steames cuccom, és soha nem volt ilyen problémám. A frissítést meg ki lehet kapcsolni.

A uTorrentet telerakták reklámmal, meg eszi nálam a memóriát, és belassul tőle a gép, úgyhogy váltottam qBittorrentre. Az UI majdnem ugyanaz, csak nem reklámoz, és fasza, úgyhogy ajánlom nektek is.

TCH (statz)

#1, Főfasz (10443)

958 | #2992 | ^ | Idézet | Thu, 26 Dec 2013 22:28:09 +01

31.46.*.*

*.catv.pool.telekom.hu

@kemi:
Nekem is van pár steames cuccom, és soha nem volt ilyen problémám.

Én értem, hogy van akinek működik, de amint látjátok, van akinek nem.

@kemi:
A frissítést meg ki lehet kapcsolni.

Ez a csávó is kikapcsolta.

@kemi:
A uTorrentet telerakták reklámmal, meg eszi nálam a memóriát, és belassul tőle a gép, úgyhogy váltottam qBittorrentre. Az UI majdnem ugyanaz, csak nem reklámoz, és fasza, úgyhogy ajánlom nektek is.

Igen, sajnos az uTorrent a 2.0.4 óta egyre szarabb. Úgyhogy nekem azóta is a 2.0.4 van. Ezzel a qBittorrenttel csak egy baj van. Az uTorrent 200 kiló, ez meg 10 mega.

Vándékkönyv v4.1.3:
• Pety ötlete az idézésre implementálva, innentől mutatja, hogy melyik post az, amit idéztünk. (Ezt mondjuk kézzel eddig is lehetett csinálni, külső portáloknál csináltuk is, de így nyilván kényelmesebb. :) )

TCH (statz)

#1, Főfasz (10443)

2151 | #2993 | ^ | Idézet | Thu, 26 Dec 2013 22:57:41 +01

31.46.*.*

*.catv.pool.telekom.hu

Most már kezd kihullani az összes létező hajam.
Szükségem lenne egy olyan usleep függvényre, ami képes ténylegesen 1 µszekundumot várakozni.
Na most, a következő lehetőségeket találtam.
• fpNanoSleep() a FreePascal színeiben. Ez nagyon király. Pont ez az, amire gondoltam. Csak egy dolgot nem tud, amire viszont szükségem lenne. Működni. Merthogy kurwára nem működik.
• rdtsc a sux86 "processzorok" utasításkészletének színeiben. Van a fax86-okban egy counter, ami az órajelnek megfelelő sebességgel inkrementálódik és ezzel lehet lekérni. Ez is pont jó lenne nekem, így ugyan assemblerben kell megírnom az időzítőt, de hát az nem baj. Az viszont már annál nagyobb baj, hogy ehhez kéne az órajel! Ezt ugyan még ki lehet mérni úgy, hogy lekéred a tick-countert, vársz egy másodpercet, lekéred megint és a különbséget 1000000-val elosztva megkapod, hogy 1 µsec az hány tick. Viszont az órajel már kurwa régen nem statikus! Innentől kezdve viszont minden várakozás előtt ki kéne mérnem, hogy most mennyi az órajel! Marha fasza lenne úgy várakozni 1 µszekundumot, hogy közben várok egymilliót... PC-s SUXXX!
• Rendszeridő lekérése, ugyanis az is µszekundumban van mérve. Utána addig kérem le a rendszeridőt, amíg egyezik az először lekérttel. Na ja. Übergány...viszont működik...10 µszekundumos nagyságrendben! Ha lejjebb megyek és 1-2 µs-t akarok vele időzíteni, akkor késik! AAAARGH!!!

Komolyan nem hiszem el bazdmeg, ennyire túl nagy kérés ez?! Itt van egy kibaszott gép, benne egy 2.4 GHz-en járó procival, ami azt jelenti, hogy egy tick kevesebb, mint fél nanoszekundumig tart, ez kevesebb, mint a µszekundum kétezred része, hát nem hiszem el, hogy ennyire képtelenség rajta egy olyan időzítőt összehozni, ami a sebességétől több mint kétezerszer lassabb! Miezmár?!

Sz*rk: 2015.12.20.: Közben találtam egy elég jó megoldást, ami nincs túlkomplikálva. A gép egyes portjainak az elérése pontosan 1 µsec-ig tart az ISA bus latency miatt.

#include <sys/io.h>

ioperm(0x80, 1, 1);

És utána ha várni akarunk 1 mikroszekundumot, akkor

inb(0x80);

TCH (statz)

#1, Főfasz (10443)

2757 | #2994 | ^ | Idézet | Fri, 27 Dec 2013 02:40:16 +01

31.46.*.*

*.catv.pool.telekom.hu

Minthogy minden épeszű módszer kudarcot vallott, így kénytelen voltam egy olyan módszerhez folyamodni, ami manapság nem igazán nevezhető épeszűnek. Most mondjam, hogy persze, hogy ez vált be? A lényeg, hogy a rendszerórából lekérem az időt, utána lefuttatok egy 4 giga méretű üres ciklust, majd megint lekérem az időt és utána a 4 gigát elosztva az eltelt idővel, megkapom, hogy hány iteráció jut egy µsec-re. Utána ezt felszorzom annyival, amennyi µszekundumot várni akarok és annyiszor pörgetem körbe az üres ciklust. Az eredmény egyelőre kielégítő, mindössze 4-5 ezrelékes eltérés van a várt és a mért eredmény között, tehát elméletileg jelen pillanatban, ha 1 µs-t várakoztatok, akkor az valójában 1.005 µsec-ig fog tartani.
Nem elég jó, de mindenképpen haladás a többi totál használhatatlan szeméthez képest. Ha sikerül egy ezrelék - azaz egy nanoszekundum - alá nyomni a különbséget, akkor az már oké lesz.

Megosztom a kódot az utókorral, hátha más többre jut.

unit cusleep_lib;

interface

procedure init_cusleep;
procedure cusleep(usec: longint);

implementation

uses unix;

var
	cusleep_time: longint;

procedure init_cusleep;
var
	bt: int64;
	tv: timeval;
label l0;
begin
	fpgettimeofday(@tv, nil);
	bt := (tv.tv_sec * 1000000) + tv.tv_usec;
	asm

		{$ifdef cpu386}
		xorl %eax, %eax
		xorl %ecx, %ecx
		l0:
		incl %ecx
		cmpl %eax, %ecx
		jne l0
		{$endif cpu386}

		{$ifdef cpux86_64}
		xorl %eax, %eax
		xorl %ecx, %ecx
		l0:
		incl %ecx
		cmpl %eax, %ecx
		jne l0
		{$endif cpux86_64}

		{$ifdef cpupowerpc}
		xor r0, r0, r0
		xor r1, r1, r1
		l0:
		addi r1, r1, 1
		cmp cr0, 1, r0, r1
		bne cr0, l0
		{$endif cpupowerpc}

	end;
	fpgettimeofday(@tv, nil);
	cusleep_time := $100000000 div (((tv.tv_sec * 1000000) + tv.tv_usec) - bt);
end;

procedure cusleep(usec: longint); assembler;
label l0;
asm

	{$ifdef cpu386}
	movl usec, %eax
	movl cusleep_time, %ecx
	mul %ecx
	xorl %ecx, %ecx
	l0:
	incl %ecx
	cmpl %eax, %ecx
	jne l0
	{$endif cpu386}

	{$ifdef cpux86_64}
	movl usec, %eax
	movl cusleep_time, %ecx
	mul %ecx
	xorl %ecx, %ecx
	l0:
	incl %ecx
	cmpl %eax, %ecx
	jne l0
	{$endif cpux86_64}

	{$ifdef cpupowerpc}
	ld r1, 0(usec)
	ld r0, 0(cusleep_time)
	mul r0, r0, r1
	xor r1, r1, r1
	l0:
	addi r1, r1, 1
	cmp cr0, 1, r0, r1
	bne cr0, l0
	{$endif cpupowerpc}

end;

end.

És a tesztprogram.

program test;

uses cusleep_lib, unix;

var
	i: longint;
	bt: int64;
	tv: timeval;

begin
	init_cusleep;
	fpgettimeofday(@tv, nil);
	bt := (tv.tv_sec * 1000000) + tv.tv_usec;
	for i := 1 to 10000000 do
	begin
		cusleep(1);
	end;
	fpgettimeofday(@tv, nil);
	write(((tv.tv_sec * 1000000) + tv.tv_usec) - bt, #10);
end.

TCH (statz)

#1, Főfasz (10443)

188 | #2995 | ^ | Idézet | Fri, 27 Dec 2013 10:57:37 +01

31.46.*.*

*.catv.pool.telekom.hu

Vándékkönyv v4.1.4:
• BBCode interpreter v3.2.2: CSS módban a color, ncolor és face tag-ek is a méretet akarták beállítani. A kontrolcékontrolvé átka. :P

TCH (statz)

#1, Főfasz (10443)

78 | #2996 | ^ | Idézet | Fri, 27 Dec 2013 18:54:01 +01

31.46.*.*

*.catv.pool.telekom.hu

Bazdmeg, most olvastam egy fasza poént a windóz hétre: windóz hate! XDDDDDDDDD

saxus (statz)

#9, Agyfasz (419)

706 | #2997 | ^ | Idézet | Sun, 29 Dec 2013 00:23:36 +01

81.182.*.*

*.pool.t-online.hu

Meg valahol ugy olvastam vagy tanultam, hogy 10us-enkent frissiti a rendszeridot eleve, azert nem tudsz lejjebb menni. Bar gondolom idaig te is eljutottal.

Viszont sztem ezzel meg az a gond, hha fut barmi mas is (mondjuk egy oprendszer), siman barmikor keresztbeverheti neked az oprendszer alattad. Egyreszt azert, mert siman kaphatsz egy taskvaltast barmikor. Sima milliseces sleepek, timer implementaciok pl. siman visszaadjak a vezerlest az OS-nek, hogy majd az OS ebressze. Plusz ma mar minden ertelmesebb idozito probalja csoportositani a taskokat, hogy inkabb egybefuggoen fusson tobb, mint sokszor keves az energiagazdalkodasi lehetosegek miatt.

Egyebkent hova van neked szukseged 1us sleepre?

TCH (statz)

#1, Főfasz (10443)

877 | #2998 | ^ | Idézet | Sun, 29 Dec 2013 00:38:20 +01

31.46.*.*

*.catv.pool.telekom.hu

Nekem is ez volt a bajom az összes felkínált időzítő megoldással, hogy nem használható egy modern gépen, modern oprendszer alatt. Ez elméletileg azért jó, mert ez nem "vár" (értsd: nincs felfüggesztve, nem idle), hanem fut egy ciklus megállás nélkül (terheli is a processzort, mint állat).
Persze lehet, hogy az elmélet téves, ezt majd a gyakorlat fogja igazolni, a mérések egyelőre kielégítő eredményt mutatnak. Egyébként normál felhasználás mellett volt mérve, azaz ment mind a négy mag, a kernel kapcsolgatta az órajelet 800 MHz és 2.4 GHz között és a magok között is ugráltatta a taskot (láttam a kijelzőn) és ezt nem én kértem tőle, (tehát nem volt vezérelt, ellenőrzött) hanem az oprendszer csinálta.

Szükségem 1 µs-es időzítésre meg a cikluspontos (1 MHz) 6502 emulátoromban van szükség. Ott egy ciklus pontosan 1 µs-ig tart.

saxus (statz)

#9, Agyfasz (419)

593 | #2999 | ^ | Idézet | Sun, 29 Dec 2013 08:12:21 +01

81.182.*.*

*.pool.t-online.hu

Igen, annyit azert meg ki tudtam olvasni a kodbol. Miert nem mered, hogy mennyit csuszik el es korrigalod annyival a ciklusod?

"a kernel kapcsolgatta az órajelet 800 MHz és 2.4 GHz között és a magok között is ugráltatta a taskot (láttam a kijelzőn)"

Persze, mert nem linearis a CPU teljesitmenyfelvetele. Bar azert altalaban abbol is megprobalnak minel kevesebbet hasznalni, mert sok szempontbol nem jo az. (na meg, NUMA rendszernel lehet, hogy a masik mag 100 km-rel odebb van...) azt meg hogy hol a pontos optimum, azt valoszinuleg az intel/amd mernokokon kivul senki nem tudja.

saxus (statz)

#9, Agyfasz (419)

127 | #299a | ^ | Idézet | Sun, 29 Dec 2013 08:12:57 +01

81.182.*.*

*.pool.t-online.hu

Hja, CPU energiafogyasztashoz akartam meg irni: hogy azert mondjuk nem mindegy, hogy egy noti bir masfel-ket orat, vagy 6-7-et.

TCH (statz)

#1, Főfasz (10443)

1579 | #299b | ^ | Idézet | Sun, 29 Dec 2013 12:36:07 +01

31.46.*.*

*.catv.pool.telekom.hu

@saxus:
Miert nem mered, hogy mennyit csuszik el es korrigalod annyival a ciklusod?

Mert fingom sincs, hogy hogy korrigálhatnék 5 nanoszekundumnyi csúszást. :]
A nanoszekundumos tartomány már jócskán a mai PC-k órajelideje (1/GHz = ns), ennek megfelelően ns nagyságrendű csúszásokat nem lehet kimérni: ha az asm kódban erre lenne vizsgálat, akkor már az is belezavarna ennyit vagy annyit, ha meg még a korrigálás is benne lenne, (pl. NOP injektálás valahova, vagy egy NOP blokk átugrásának újraparaméterezése), akkor az meg pláne. A végeredmény sokkal nagyobb csúszás lenne, mint amit korrigálni akartam. Egy 2.4 GHz-en járó magon egy "tick" vagy más néven ciklus az usque 0.41 + 2/3 ns. Egy utasítás végrehajtása 2-N ciklusig tart, tehát már pl. egy NOP utasítás is megeszik majdnem 1 ns-t és akkor még nem is csináltunk semmit.
Egyszerűen arról van szó, hogy egy X GHz-es processzoron (ahol X < ~50) nem lehet nanoszekundumnyi eltéréseket korrigálni. Pontosabb ciklust talán lehet írni, de menetközbeni korrigálásra nincs esély, mert ahogy leírtam, a korrigálásra szolgáló utasítások nagyobb differenciát eredményeznének, mint amennyi eredetileg volt.

@saxus:
Hja, CPU energiafogyasztashoz akartam meg irni: hogy azert mondjuk nem mindegy, hogy egy noti bir masfel-ket orat, vagy 6-7-et.

Nyilván nem, de ez az én kódom esetében irreleváns, mert párhuzamos port a notikon már baromi régen nincsen.

Nem kerestek épp embert az Empohoz? Mert én épp állást keresek.

saxus (statz)

#9, Agyfasz (419)

218 | #299c | ^ | Idézet | Sun, 29 Dec 2013 14:24:02 +01

81.182.*.*

*.pool.t-online.hu

Hulye kerdes, de ha levonnal 5-ot itt?

cusleep_time := $100000000 div (((tv.tv_sec * 1000000) + tv.tv_usec) - bt);

Btw. ebben az AT&T stilusu ASM kodban forditva van a cel es a forrasregiszter a MOV-nal?

saxus (statz)

#9, Agyfasz (419)

134 | #299d | ^ | Idézet | Sun, 29 Dec 2013 14:40:53 +01

81.182.*.*

*.pool.t-online.hu

Hja es nem. Karacsony elott szoktunk altalaban embereket keresni, de akkor is sales es raktar temakorben. IT-re csak kihalasos alapon.

TCH (statz)

#1, Főfasz (10443)

1382 | #299e | ^ | Idézet | Sun, 29 Dec 2013 17:24:44 +01

31.46.*.*

*.catv.pool.telekom.hu

@saxus:
Hulye kerdes, de ha levonnal 5-ot itt?

Nem hülye kérdés, mert a ciklusszám basztatásával valóban lehet ezen még hangolni és közelebb mászni a célhoz 1-2 ns-el; csak egy a baj: mennyit vonjunk le, vagy adjunk hozzá? Konstans 5 nem biztos, hogy jó, mert ez ciklusszám, ami egyik gépen ennyi idő, másikon annyi, sőt, akár ugyanazon a gépen is, egyik futásnál ennyi, másiknál annyi, az órajel függvényében. Szóval jó helyen keresgészel, csak az a baj, hogy még mindig nem tudjuk kimérni, hogy mennyi az annyi. Max esetleg úgy, hogy méri 10 másodpercig és a várt/mért különbségből számol egy offsetet. De akkor így a program inicializálása baromi sokáig fog tartani.

@saxus:
Btw. ebben az AT&T stilusu ASM kodban forditva van a cel es a forrasregiszter a MOV-nal?

Az intelhez képest igen, fordítva van, de amúgy az inteles a fordított. Kicsit nekem is szokatlan így x86 kódot írni, de így azért logikusabb, hogy elöl a forrás, hátul a cél (68k-n is így van), meg az is reálisabb, hogy én specifikálom az operandus hosszát (az is így van 68k-ban). Meg ami még fontosabb, ezt a szintaxist támogatják a fordítók, nem csak a FreePascal, hanem a GCC és a CLang is. (Mondjuk FP az támogatja az inteles szintaxist is, csak át kell kapcsolni.)

@saxus:
IT-re csak kihalasos alapon.

Remek.

TCH (statz)

#1, Főfasz (10443)

2622 | #299f | ^ | Idézet | Sun, 29 Dec 2013 18:00:24 +01

31.46.*.*

*.catv.pool.telekom.hu

@TCH:
Max esetleg úgy, hogy méri 10 másodpercig és a várt/mért különbségből számol egy offsetet. De akkor így a program inicializálása baromi sokáig fog tartani.

Viszont vehetünk kisebb időszeletet is, maximum a mérés nem lesz annyira pontos. Én most átírtam a mérést:

unit cusleep_lib;

interface

procedure cusleep(usec: longint);
procedure init_cusleep;

implementation

uses unix;

var
	cusleep_time: longint;

procedure cusleep(usec: longint); assembler;
label l0;
asm

	{$ifdef cpu386}
	movl usec, %eax
	movl cusleep_time, %ecx
	mul %ecx
	xorl %ecx, %ecx
	l0:
	incl %ecx
	cmpl %eax, %ecx
	jne l0
	{$endif cpu386}

	{$ifdef cpux86_64}
	movl usec, %eax
	movl cusleep_time, %ecx
	mul %ecx
	xorl %ecx, %ecx
	l0:
	incl %ecx
	cmpl %eax, %ecx
	jne l0
	{$endif cpux86_64}

	{$ifdef cpupowerpc}
	ld r1, 0(usec)
	ld r0, 0(cusleep_time)
	mul r0, r0, r1
	xor r1, r1, r1
	l0:
	addi r1, r1, 1
	cmp cr0, 1, r0, r1
	bne cr0, l0
	{$endif cpupowerpc}

end;

procedure init_cusleep;
var
	bt: int64;
	tv: timeval;
	i: longint;
label l0;
begin
	fpgettimeofday(@tv, nil);
	bt := (tv.tv_sec * 1000000) + tv.tv_usec;
	asm

		{$ifdef cpu386}
		xorl %eax, %eax
		xorl %ecx, %ecx
		l0:
		incl %ecx
		cmpl %eax, %ecx
		jne l0
		{$endif cpu386}

		{$ifdef cpux86_64}
		xorl %eax, %eax
		xorl %ecx, %ecx
		l0:
		incl %ecx
		cmpl %eax, %ecx
		jne l0
		{$endif cpux86_64}

		{$ifdef cpupowerpc}
		xor r0, r0, r0
		xor r1, r1, r1
		l0:
		addi r1, r1, 1
		cmp cr0, 1, r0, r1
		bne cr0, l0
		{$endif cpupowerpc}

	end;
	fpgettimeofday(@tv, nil);
	cusleep_time := ($100000000 div (((tv.tv_sec * 1000000) + tv.tv_usec) - bt));
	
	bt := (tv.tv_sec * 1000000) + tv.tv_usec;
	for i := 1 to 1000000 do
	begin
		cusleep(1);
	end;
	fpgettimeofday(@tv, nil);
	cusleep_time := cusleep_time - (((((tv.tv_sec * 1000000) + tv.tv_usec) - bt) - 1000000) div 1000);
end;

end.

Amint látjátok, itt az inicializáló, a ciklusmérés után, mindjárt mér is egy másodpercet a timer függvénnyel, aztán a mért eredményből kivonja a vártat és az eredményt osztja ezerrel (lévén ugye itt µszekundumokat mértünk, de nanoszekundumokat számolunk) és az egészet kivonja az eredeti ciklusszámból. Az operandusok előjelesek, azaz, ha épp hosszabbítani kellene a várakozást, akkor negatív számot von ki (azaz összead), tehát mind a két irányba jó.
A végeredmény elég jó, a mért/várt különbség ~0.5%-ról ~0.07%-ra csökkent, azaz valamivel egy ezrelék alá. Tehát most már egy µszekundum alatt kevesebbet csúszik, mint 1 ns.