Re: Mesurar rendiment d'una aplicació

[Ernest Adrogué]

Hola,

2021-06- 2, 08:13 (+0200); Leopold Palomo-Avellaneda escriu:
> Però és una passada perquè el CPU time hauria de ser més o menys constant i
> no ho és. Nosaltres hem trobat variacions de fins al un 10%.

Però un 10% quant és en termes absoluts?  No és el mateix 30 segons que
500 milisegons.

A les llistes de computació científica, la gent sempre reporta
estadístiques sobre el temps d'execució, mai un únic temps d'execució.
O sigui el que fan és executar el programa o funció repetidament moltes
vegades i calculen la mitjana.  De fet tenen eines d'anàlisi de
rendiment que ho fan automàticament.

Salutacions.

Re: Mesurar rendiment d'una aplicació

[Josep Lladonosa]

On Wed, 2 Jun 2021 at 20:27, Leopold Palomo-Avellaneda 
wrote:

> El 2/6/21 a les 9:27, Josep Lladonosa ha escrit:
> [...]
>
> > Hola, Leo,
> >
> > Has aportat una pregunta molt interessant. Si més no m'hi has fet rumiar
> > una bona estona.
> >
> > Podria ser que la causa de les variacions sigui la temperatura?
>
> No, està en un CPD, i té condicions òptimes.
>
> > Els nuclis dels processadors redueixen la freqüència dels nuclis quan la
> > temperatura baixa.
> >
> >
> https://www.pugetsystems.com/labs/articles/Impact-of-Temperature-on-Intel-CPU-Performance-606/
> > <
> https://www.pugetsystems.com/labs/articles/Impact-of-Temperature-on-Intel-CPU-Performance-606/
> >
>
> Sí, però no. Té aire condicionat 24/7/365
>

M'estàs parlant de la sala on es troba el processador.

Jo parlava de les temperatures dels nuclis. Hi influeix la capacitat de
dissipadors i ventiladors per emportar-se l'escalfor dels processadors.
Pots tenir la sala amb aire condicionat i els processadors treballant
tranquil·lament a 60/70/80 graus centígrads. Aquestes variacions poden fer
fluctuar aquests càlculs de temps.

SALUT!
Josep


>
>
> Leo
>
> --
> --
> Linux User 152692 GPG: 05F4A7A949A2D9AA
> Catalonia
> -
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>


-- 
--
Salutacions...Josep
--

Re: Mesurar rendiment d'una aplicació

[Xavi Drudis Ferran]

El Wed, Jun 02, 2021 at 08:24:30PM +0200, Leopold Palomo-Avellaneda deia:
> biblioteca de codi tancat. Però tu llences l'aplicació i totes les cpu
> és posen a treballar com a perturbades.
> 

Clar, pobretes. Si jo fos una CPU d'aquestes també m'escaquejaria com pogués
fins que arribés el torn de l'apicació lliure

;op

Re: Mesurar rendiment d'una aplicació

[Leopold Palomo-Avellaneda]

El 2/6/21 a les 20:53, Narcis Garcia ha escrit:
> __
> I'm using this dedicated address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> El 2/6/21 a les 20:21, Leopold Palomo-Avellaneda ha escrit:
>> El 2/6/21 a les 10:19, Narcis Garcia ha escrit:
>>> Per a controlar tot allò que afecta a la CPU, crec que el millor és
>>> virtualitzar. Fins i tot és possible separar la màquina virtual de l'ús
>>> directe del maquinari real.
>>>
>>
>> no ho crec. Jo voldria poder fer servir tota la capacitat de la màquina,
>> no voldria una capa de virtualització.
>>
>> Leo
>>
> 
> El teu objectiu és executar ràpid o bé mesurar el cost d'un procés per a
> planificar execucions futures?
> És la única manera que veig de controlar una CPU.

el meu objectiu és mesurar un procés per poder comparar. Per exemple
donar-li a un algoritme un temps límit de forma que si el comparo amb un
altre tingui les mateixes condicions o quasi similars.

> Tota la resta és creuar dits i esperar que la primera, segona, tercera,
> etc. execucions vagin igual en maquinari real.
> És la diferència entre fer una mesura a l'aire lliure o en condicions de
> laboratori.

Sí 


Leo


-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: Mesurar rendiment d'una aplicació

[Narcis Garcia]

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 2/6/21 a les 20:21, Leopold Palomo-Avellaneda ha escrit:
> El 2/6/21 a les 10:19, Narcis Garcia ha escrit:
>> Per a controlar tot allò que afecta a la CPU, crec que el millor és
>> virtualitzar. Fins i tot és possible separar la màquina virtual de l'ús
>> directe del maquinari real.
>>
> 
> no ho crec. Jo voldria poder fer servir tota la capacitat de la màquina,
> no voldria una capa de virtualització.
> 
> Leo
> 

El teu objectiu és executar ràpid o bé mesurar el cost d'un procés per a
planificar execucions futures?
És la única manera que veig de controlar una CPU.

Tota la resta és creuar dits i esperar que la primera, segona, tercera,
etc. execucions vagin igual en maquinari real.
És la diferència entre fer una mesura a l'aire lliure o en condicions de
laboratori.


Narcis Garcia

Re: Mesurar rendiment d'una aplicació

[Leopold Palomo-Avellaneda]

Bones,

trobava a faltar els teus correus

El 2/6/21 a les 10:25, Xavi Drudis Ferran ha escrit:
> El Wed, Jun 02, 2021 at 08:13:46AM +0200, Leopold Palomo-Avellaneda deia:
>> El 1/6/21 a les 23:00, Àlex ha escrit:
>>> Aquí hi ha diferents de codi per mesurar temps d'us de cpu (cpu time) i
>>> el temps total (wall time). A tu t'interessa el cpu time:
>>>
>>> https://levelup.gitconnected.com/8-ways-to-measure-execution-time-in-c-c-48634458d0f9
>>>
>>>
>> Genial!!!
>>
>> Però és una passada perquè el CPU time hauria de ser més o menys constant i
>> no ho és. Nosaltres hem trobat variacions de fins al un 10%.
>>
>> Leo
> 
> Jo no hi entenc però és que no veig perquè la CPU hauria de ser
> constant.  Si agafes un model de processador com el que feiem a primer
> de carrera a Computadors potser sí.  Però amb les complicacions que
> tenen les CPUs actuals ja és molt si aconsegueixen que els resultats
> siguin deterministes. Que el temps sigui determinista en condicions
> diferents és demanar molt.

Estem totalment d'acord.

> Algú ha parlat de temperatura, i sí, els processadors poden baixar la
[...]

no és temperatura.

> 
> Quan l'ordinador té diferents processadors i cada processador
> diferents nuclis, també pots tenir més rendiment si tots els
> processos/fils de la teva aplicació acaben a nuclis del mateix
> processador i comparteixen alguna cache o tenen rutes més curtes per
> comunicar-se. Si al sistema hi ha molts processos potser el linux no
> aconsegueix distribuir els teus tan òptimament.  Fulleja per aquí per
> una idea del merder que representa
> https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/

Brutal He de mirar-ho amb calma.

[...]

> 
> Has mirat perf ?
> https://perf.wiki.kernel.org/index.php/Tutorial

No, ara ho estic mirant.

Moltes gràcies.

Leo



-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: Mesurar rendiment d'una aplicació

[Leopold Palomo-Avellaneda]

El 2/6/21 a les 9:27, Josep Lladonosa ha escrit:
[...]

> Hola, Leo,
> 
> Has aportat una pregunta molt interessant. Si més no m'hi has fet rumiar
> una bona estona.
> 
> Podria ser que la causa de les variacions sigui la temperatura?

No, està en un CPD, i té condicions òptimes.

> Els nuclis dels processadors redueixen la freqüència dels nuclis quan la
> temperatura baixa.
> 
> https://www.pugetsystems.com/labs/articles/Impact-of-Temperature-on-Intel-CPU-Performance-606/
> 

Sí, però no. Té aire condicionat 24/7/365


Leo

-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: Mesurar rendiment d'una aplicació

[Leopold Palomo-Avellaneda]

El 2/6/21 a les 10:31, Àlex ha escrit:
> Leo,
> 
> no puc deixar de rumiar en la teva pregunta. No conec el tema, però com
> t'han dit, és molt interessant.

Uff, i tant.

> El servidor on s'executa l'aplicació, té una o més CPUs multinucli?

és un servidor Dell amb dues cpus i 20 cores cadascuna.

> Està l'aplicació preparada per executar-se en paral.lel en vàries CPUs o
> per emprar varis nuclis dins d'una CPU?

Les porves que hem fet executa una aplicació que fa servir una
biblioteca de codi tancat. Però tu llences l'aplicació i totes les cpu
és posen a treballar com a perturbades.

> L'aplicació fa us de GPU de targetes gràfiques?

No, només cpu. A més, el servidor té una gràfica molt simple.

> En quin llenguatge està programada l'aplicació?

El core de l'aplicació de IBM crec que està en C o C++. Té "bindings"
java, python i C++. També té un IDE que en el fons crida a aquest core.


Leo


-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: Mesurar rendiment d'una aplicació

[Leopold Palomo-Avellaneda]

El 2/6/21 a les 10:19, Narcis Garcia ha escrit:
> Per a controlar tot allò que afecta a la CPU, crec que el millor és
> virtualitzar. Fins i tot és possible separar la màquina virtual de l'ús
> directe del maquinari real.
> 

no ho crec. Jo voldria poder fer servir tota la capacitat de la màquina,
no voldria una capa de virtualització.

Leo

-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: consulta unattended-upgrades

[Eloi]

Explico la meva experiència posant tres exemples:

* Ordinador de treball amb Debian testing: *sempre* actualitzat a mà. A 
més, com que testing no té suport per actualitzacions de seguretat, en 
aquest escenari unattended-upgrades faria més mal que bé.


* Ordinador de treball amb Debian stable (familiar): unattended-upgrades 
configurat només per a les actualitzacions de seguretat. Només en casos 
molt específics un programa salta de versió (penso, per exemple, en el 
Mozilla Firefox), des de Debian sempre es té molta cura de traslladar 
només els pedaços que resolen els problemes de seguretat sense incloure 
altres canvis funcionals, i s'ha de reconèixer que ho fan molt molt bé.


* Servidor en producció amb Debian stable: actualitzo a mà durant les 
finestres de manteniment per necessitats de servei. En aquest cas 
considero imprescindible estar subscrit a debian-security-announce per 
fer-ne una gestió adequada.


Per exemple, no fa ni mitja hora ha saltat avís a la llista 
d'actualització per a firefox-esr:




Què faré jo?

* Ordinador amb testing: tocarà actualitzar-lo

* Ordinador amb stable: ja s'actualitzarà

* Servidor amb stable: no té firefox instal·lat, ni em preocupo

Faig constar que aquest criteri *només* l'aplico a Debian, no a 
derivades com Ubuntu (que evito com la pesta).


YMMV.

Re: consulta unattended-upgrades

[Griera]

A dimecres 02 de juny 2021,  vàreu escriure:

> On Wed, Jun 02, 2021 at 07:36:31AM +, xavi wrote:
> > 
> > Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per això
> > voldria saber les vostres opinions, aviam què opineu :)
> 
> Crec que la clau radica en diferenciar si l'actualització és de
> seguretat o incorpora millores.

Bé, jo només ho tinc activat per les actualitzacions de seguretat. Les altres 
entenc que poden sé més complexes i les faig a ma.

> 
> Potser la recomanació de
> https://packages.debian.org/en/jessie/cron-apt seria la clau.
> 

Re: consulta unattended-upgrades

[Griera]

A dimecres 02 de juny 2021,  vàreu escriure:

> __
> I'm using this dedicated address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> El 2/6/21 a les 10:23, Griera ha escrit:
> > A dimecres 02 de juny 2021,  vàreu escriure:
> > 
> >> Hola,
> >>
> >> No sé si aquesta pregunta vorejaria l'offtopic, però per si de cas us la 
> >> faig. A la feina i fins i tot a casa, a totes les meves màquines debian 
> >> i ubuntu faig servir sempre unattended-upgrades. Particularment en 
> >> aquelles que tenen accés a l'exterior (servidors i tal). Per mi és una 
> >> eina d'actualització de seguretat ràpida i potent. Però estic llegint a 
> >> grups de Telegram, i en alguna opinió d'algun company, que 
> >> unattended-upgrades mai, que les actualitzacions a mà.
> >>
> >> No acabo d'entendre què tenen en contra, que no se'ls hi actualitzin 
> >> programes que tinguin extremadíssimament configurats a mà i que tinguin 
> >> por que una actualització els aixafi la configuració prèvia? o que fent 
> >> servir unattended-upgrades un podria arribar a confiar-se en excés i 
> >> prefereixen anar actualitzant a mà? (aquest últim argument per mi seria 
> >> del nivell com no voler fer servir el wifi perquè com que te'l poden 
> >> crackejar).
> >>
> >> Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per 
> >> això voldria saber les vostres opinions, aviam què opineu :)
> >>
> >> Records i gràcies per endavant.
> >>
> >> x.
> >>
> > 
> > Jo, usuari vulgar i de perfil molt baix, ho tinc activat en els diferents 
> > ordinadors. Per mi és un tema de seguretat que preval per sobre d'altres 
> > consideracions. No tenir instal·lades les actualitzacions de seguretat pot 
> > portar a ensurts. Fa unes setmanes vaig obrir i connectar a Internet un 
> > ordinador que feia uns anys que no obria (¿un? ¿dos? ¿tres?). Tenia 
> > instal·lat una versió del firefox vulnerable (no s'havia actualitzat) i em 
> > van pispar el fitxer amb totes les contrasenyes desades. Per sort, totes 
> > banals: no en deso cap crítica. Però l'ensurt no te'l treu ningú.
> > 
> > Records.
> > 
> 
> Compte perquè el concepte de seguretat també és aplicable a poder
> comptar amb l'ordinador quan el necessites.

Sí, tens tota a raó, Narcís. El dia que provoqui problemes, ho deixaré de fer 
servir. De moment, m'ha funcionat i hi tinc confiança . . . fins que la perdi.


> 
> 
> Narcis Garcia
> 

Re: consulta unattended-upgrades

[Alex Muntada]

Deia l'Àlex:

> La meva experiència és que unattended-upgrades funciona bé en
> Debian estables i Ubuntus LTS sobre les actualitzacions de
> seguretat.

La meva experiència també és aquesta, tot i que en alguns casos
he patit problemes amb Ubuntu perquè l'actualització de seguretat
també incorporava canvis no relacionats i que no eren compatibles
(els paquets en qüestió eren dels lxc). Hi ha més risc que passi
això com més vella sigui la LTS (que va ser el cas del problema
amb el lxc: van portar una versió corregida d'una LTS més nova
a una de més vella).

Suposo que de vegades no és trivial resoldre un problema de
seguretat en versions antigues i cal forçar un canvi més gran i
amb l'u-u no veus els avisos corresponents. Però em sembla
recordar que si instal·les apt-listchanges els avisos s'envien
també per correu a root. També cal tenir en compte que els que
fem paquets també ens equivoquem de vegades...

En qualsevol cas, la clau està en el número de servidors a
gestionar i de com de crític siguin els seus serveis. Si en tens
un número prou gran no pots fer les actualitzacions manualment de
cap de les maneres i has de buscar altres estratègies (només els
de seguretat, només alguns paquets, congelar versions, tenir
imatges pròpies i refer-les regularment, alertes dels paquets
disponibles, monitoritzar els serveis, tenir una bateria de tests
per assegurar que funcionen, etc.).

També val a dir que de vegades u-u no pot actualitzar algun
paquet pel motiu que sigui i cal fer-ho manualment. Quan això ha
passat m'ha funcionat molt bé utilitzar dsh per executar la
mateixa ordre a un grup de servidors. També recordo que m'havien
parlat molt bé del apt-dater, però no l'he provat.

> Jo també soc dels que m'agrada instal.lar a mà actualitzacions,
> però les meves circumstàcies són que a casa treballo amb Debian
> Testing, on un cop a l'any alguna actualització pot posar el meu
> sistema a fer una mica el ruc.

Jo treballo amb estable per l'escriptori i unstable per a fer els
paquets. En tots dos casos actualitzo a mà per estar al cas dels
canvis que es fan i per no perdre'm els detalls.

> Altres cops les circumstàcies han estat instal.lar un servei
> amb Debian estable a algún lloc on no el podria administrar,
> i allà no veig millor solució que emprar unattended-upgrades.

Als ordinadors que he configurat a d'altra gent també els poso
actualitzacions automàtiques i en la mitja dotzena de servidors
que administro tinc configurat els u-u de seguretat perquè no puc
dedicar el temps necessari per fer-ho manualment. En aquests
casos utilitzo eines com logwatch i apt-listchanges per estar al
cas del que va passant.

Al final es tracta de triar on hom vol invertir el seu temps.

Salut,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Re: consulta unattended-upgrades

[Àlex]

Bones Xavi

La meva experiència és que unattended-upgrades funciona bé en Debian
estables i Ubuntus LTS sobre les actualitzacions de seguretat.

Jo també soc dels que m'agrada instal.lar a mà actualitzacions, però les
meves circumstàcies són que a casa treballo amb Debian Testing, on un
cop a l'any alguna actualització pot posar el meu sistema a fer una mica
el ruc.

Altres cops les circumstàcies han estat instal.lar un servei amb Debian
estable a algún lloc on no el podria administrar, i allà no veig millor
solució que emprar unattended-upgrades.

Tot depen de les circumstàncies,

Salutacions


    Àlex


El 2/6/21 a les 9:36, xavi ha escrit:
> Hola,
>
> No sé si aquesta pregunta vorejaria l'offtopic, però per si de cas us
> la faig. A la feina i fins i tot a casa, a totes les meves màquines
> debian i ubuntu faig servir sempre unattended-upgrades. Particularment
> en aquelles que tenen accés a l'exterior (servidors i tal). Per mi és
> una eina d'actualització de seguretat ràpida i potent. Però estic
> llegint a grups de Telegram, i en alguna opinió d'algun company, que
> unattended-upgrades mai, que les actualitzacions a mà.
>
> No acabo d'entendre què tenen en contra, que no se'ls hi actualitzin
> programes que tinguin extremadíssimament configurats a mà i que
> tinguin por que una actualització els aixafi la configuració prèvia? o
> que fent servir unattended-upgrades un podria arribar a confiar-se en
> excés i prefereixen anar actualitzant a mà? (aquest últim argument per
> mi seria del nivell com no voler fer servir el wifi perquè com que
> te'l poden crackejar).
>
> Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per
> això voldria saber les vostres opinions, aviam què opineu :)
>
> Records i gràcies per endavant.
>
> x.

Re: Mesurar rendiment d'una aplicació

[Xavi Drudis Ferran]

El Wed, Jun 02, 2021 at 08:13:46AM +0200, Leopold Palomo-Avellaneda deia:
> El 1/6/21 a les 23:00, Àlex ha escrit:
> > Aquí hi ha diferents de codi per mesurar temps d'us de cpu (cpu time) i
> > el temps total (wall time). A tu t'interessa el cpu time:
> > 
> > https://levelup.gitconnected.com/8-ways-to-measure-execution-time-in-c-c-48634458d0f9
> > 
> > 
> Genial!!!
> 
> Però és una passada perquè el CPU time hauria de ser més o menys constant i
> no ho és. Nosaltres hem trobat variacions de fins al un 10%.
> 
> Leo

Jo no hi entenc però és que no veig perquè la CPU hauria de ser
constant.  Si agafes un model de processador com el que feiem a primer
de carrera a Computadors potser sí.  Però amb les complicacions que
tenen les CPUs actuals ja és molt si aconsegueixen que els resultats
siguin deterministes. Que el temps sigui determinista en condicions
diferents és demanar molt.

Algú ha parlat de temperatura, i sí, els processadors poden baixar la
freqüència de rellotge si s'escalfen. També hi ha les caches (L1,L2,L3
al processador, TLBs, buffers de disc a RAM... alguns canvis de
velocitat causats per aquests te'ls deuen comptar com temps de cpu
d'usuari). Si tens pocs processos la probabilitat que les dades encara
estiguin a alguna cache després d'un parell de canvis de context
puja. Amb les mitigacions dels atacs de canals laterals a CPU
(Spectre & cia.?) potser baixi aquest efecte, però no crec que l'eliminin.

Quan l'ordinador té diferents processadors i cada processador
diferents nuclis, també pots tenir més rendiment si tots els
processos/fils de la teva aplicació acaben a nuclis del mateix
processador i comparteixen alguna cache o tenen rutes més curtes per
comunicar-se. Si al sistema hi ha molts processos potser el linux no
aconsegueix distribuir els teus tan òptimament.  Fulleja per aquí per
una idea del merder que representa
https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/

Els perifèrics també poden reaccionar diferent segons la càrrega.
Imagina't que tens processos que no toquen un disc i el disc s'arriba
a parar per estalviar energia quan aquests processos els toca una
estona llarga de CPU. Llavors quan el necessita el procés que medeixes
s'ha de tornar a accelerar (si és dels que giren, en qualsevol cas també
incorporen caches). Això hauria de ser temps de S.O. meś que d'usuari,
però no śe si es pot comptar del tot bé si fa que el procés que medeixes
surti de la CPU abans d'hora i perdi continuitat de cache o el que sigui...

Després separar temps de cpu d'usuari i de S.O. està bé, però no sé si
avui en dia hi pot haver temps de supervisors que estiguin per sobre
del S.O.  i no es vegin en cap compte (gestors de màquines virtuals,
system management, UEFI, etc.). Dubto que això influeixi molt, o
diferent segons càrrega, però qui sap.

No em facis molt de cas, parlo per parlar, no vull dir que aquests
efectes siguin significatius, vull dir que hi ha moltes coses
interconnectades.  El programador té un model simplificat d'una
màquina de von Neumann i prou (o quasi), però el S.O. i maquinari són
bastant més complicats, i això fa que el rendiment tingui tot de
peripècies.


Has mirat perf ?
https://perf.wiki.kernel.org/index.php/Tutorial

Re: consulta unattended-upgrades

[Adrià]

On Wed, Jun 02, 2021 at 07:36:31AM +, xavi wrote:
> 
> Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per això
> voldria saber les vostres opinions, aviam què opineu :)

Crec que la clau radica en diferenciar si l'actualització és de
seguretat o incorpora millores.

Potser la recomanació de
https://packages.debian.org/en/jessie/cron-apt seria la clau.

Re: Mesurar rendiment d'una aplicació

[Àlex]

Leo,

no puc deixar de rumiar en la teva pregunta. No conec el tema, però com
t'han dit, és molt interessant.

El servidor on s'executa l'aplicació, té una o més CPUs multinucli?

Està l'aplicació preparada per executar-se en paral.lel en vàries CPUs o
per emprar varis nuclis dins d'una CPU?

L'aplicació fa us de GPU de targetes gràfiques?

En quin llenguatge està programada l'aplicació?

Salut

Re: consulta unattended-upgrades

[Narcis Garcia]

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 2/6/21 a les 10:23, Griera ha escrit:
> A dimecres 02 de juny 2021,  vàreu escriure:
> 
>> Hola,
>>
>> No sé si aquesta pregunta vorejaria l'offtopic, però per si de cas us la 
>> faig. A la feina i fins i tot a casa, a totes les meves màquines debian 
>> i ubuntu faig servir sempre unattended-upgrades. Particularment en 
>> aquelles que tenen accés a l'exterior (servidors i tal). Per mi és una 
>> eina d'actualització de seguretat ràpida i potent. Però estic llegint a 
>> grups de Telegram, i en alguna opinió d'algun company, que 
>> unattended-upgrades mai, que les actualitzacions a mà.
>>
>> No acabo d'entendre què tenen en contra, que no se'ls hi actualitzin 
>> programes que tinguin extremadíssimament configurats a mà i que tinguin 
>> por que una actualització els aixafi la configuració prèvia? o que fent 
>> servir unattended-upgrades un podria arribar a confiar-se en excés i 
>> prefereixen anar actualitzant a mà? (aquest últim argument per mi seria 
>> del nivell com no voler fer servir el wifi perquè com que te'l poden 
>> crackejar).
>>
>> Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per 
>> això voldria saber les vostres opinions, aviam què opineu :)
>>
>> Records i gràcies per endavant.
>>
>> x.
>>
> 
> Jo, usuari vulgar i de perfil molt baix, ho tinc activat en els diferents 
> ordinadors. Per mi és un tema de seguretat que preval per sobre d'altres 
> consideracions. No tenir instal·lades les actualitzacions de seguretat pot 
> portar a ensurts. Fa unes setmanes vaig obrir i connectar a Internet un 
> ordinador que feia uns anys que no obria (¿un? ¿dos? ¿tres?). Tenia 
> instal·lat una versió del firefox vulnerable (no s'havia actualitzat) i em 
> van pispar el fitxer amb totes les contrasenyes desades. Per sort, totes 
> banals: no en deso cap crítica. Però l'ensurt no te'l treu ningú.
> 
> Records.
> 

Compte perquè el concepte de seguretat també és aplicable a poder
comptar amb l'ordinador quan el necessites.


Narcis Garcia

Re: consulta unattended-upgrades

[Narcis Garcia]

Subscric el què diu en Jordi 215639, i afegeixo que a les
actualitzacions automàtiques els veig dos altres inconvenients:

1. Si l'ordinador està en ús, durant les descàrregues pot haver un ús
inesperat de l'ample de banda i durant les instal·lacions un ús
inesperat de disc que pot molestar l'usuari que volia fer alguna cosa
amb prioritat en aquell moment.

2. Una actualització podria coincidir inesperadament amb una aturada
manual de l'ordinador o pitjor: Amb una interrupció elèctrica i que els
errors no es vegin fins que justament fa falta utilitzar l'ordinador.
És millor topar-se amb els problemes quan ja dedicaves el temps a
atendre les actualitzacions.


Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 2/6/21 a les 10:04, Jordi ha escrit:
> El dc. 02 de 06 de 2021 a les 07:36 +, en/na xavi va escriure:
>> Hola,
>>
>> No sé si aquesta pregunta vorejaria l'offtopic, però per si de cas us
>> la 
>> faig. A la feina i fins i tot a casa, a totes les meves màquines
>> debian 
>> i ubuntu faig servir sempre unattended-upgrades. Particularment en 
>> aquelles que tenen accés a l'exterior (servidors i tal). Per mi és
>> una 
>> eina d'actualització de seguretat ràpida i potent. Però estic llegint
>> a 
>> grups de Telegram, i en alguna opinió d'algun company, que 
>> unattended-upgrades mai, que les actualitzacions a mà.
>>
>> No acabo d'entendre què tenen en contra, que no se'ls hi actualitzin 
>> programes que tinguin extremadíssimament configurats a mà i que
>> tinguin 
>> por que una actualització els aixafi la configuració prèvia? o que
>> fent 
>> servir unattended-upgrades un podria arribar a confiar-se en excés i 
>> prefereixen anar actualitzant a mà? (aquest últim argument per mi
>> seria 
>> del nivell com no voler fer servir el wifi perquè com que te'l poden 
>> crackejar).
>>
>> Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per 
>> això voldria saber les vostres opinions, aviam què opineu :)
>>
>> Records i gràcies per endavant.
>>
>> x.
>>
> La meva opinió: trobo que si les coses es fan massa automàticament, en
> perds una mica el control. Jo abans em trobava que algunes coses no
> funcionaven com ho havien fet fins cert moment i és perquè alguna cosa
> s'havia actualitzat i alguna petita cosa funcionava de forma diferent.
> Els programes tampoc han d'estar "extremadíssimament configurats"
> perquè quelcom paràmetre deixi de funcionar o hi hagi nous paràmetres
> que facin coses noves. I això sense parlar d'actualitzacions prou
> importants ... Per això soc partidari de que el sistema m'avisi si hi
> ha actualitzacions però soc jo qui decideix quan fer-les.
> 
> salutacions
> 
> Jordi.
> 

Re: consulta unattended-upgrades

[Griera]

A dimecres 02 de juny 2021,  vàreu escriure:

> Hola,
> 
> No sé si aquesta pregunta vorejaria l'offtopic, però per si de cas us la 
> faig. A la feina i fins i tot a casa, a totes les meves màquines debian 
> i ubuntu faig servir sempre unattended-upgrades. Particularment en 
> aquelles que tenen accés a l'exterior (servidors i tal). Per mi és una 
> eina d'actualització de seguretat ràpida i potent. Però estic llegint a 
> grups de Telegram, i en alguna opinió d'algun company, que 
> unattended-upgrades mai, que les actualitzacions a mà.
> 
> No acabo d'entendre què tenen en contra, que no se'ls hi actualitzin 
> programes que tinguin extremadíssimament configurats a mà i que tinguin 
> por que una actualització els aixafi la configuració prèvia? o que fent 
> servir unattended-upgrades un podria arribar a confiar-se en excés i 
> prefereixen anar actualitzant a mà? (aquest últim argument per mi seria 
> del nivell com no voler fer servir el wifi perquè com que te'l poden 
> crackejar).
> 
> Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per 
> això voldria saber les vostres opinions, aviam què opineu :)
> 
> Records i gràcies per endavant.
> 
> x.
> 

Jo, usuari vulgar i de perfil molt baix, ho tinc activat en els diferents 
ordinadors. Per mi és un tema de seguretat que preval per sobre d'altres 
consideracions. No tenir instal·lades les actualitzacions de seguretat pot 
portar a ensurts. Fa unes setmanes vaig obrir i connectar a Internet un 
ordinador que feia uns anys que no obria (¿un? ¿dos? ¿tres?). Tenia instal·lat 
una versió del firefox vulnerable (no s'havia actualitzat) i em van pispar el 
fitxer amb totes les contrasenyes desades. Per sort, totes banals: no en deso 
cap crítica. Però l'ensurt no te'l treu ningú.

Records.

Re: Mesurar rendiment d'una aplicació

[Narcis Garcia]

Per a controlar tot allò que afecta a la CPU, crec que el millor és
virtualitzar. Fins i tot és possible separar la màquina virtual de l'ús
directe del maquinari real.



Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 1/6/21 a les 19:14, Leopold Palomo-Avellaneda ha escrit:
> Bones,
> 
> he enviat aquest missatge a la llista de caliu però ha tingut poc
> èxit... Us explico, probablement és un correu fora de tema, però
> m'agradaria preguntar aquí perquè potser alguns de vosaltres em podrien
> guiar.
> 
> Estic treballant amb alguns científics per avaluar alguns programes que
> calculen una solució per a un problema. Bàsicament fan una instància de
> ILOG CPLEX i obtenen el temps utilitzat per calcular la solució o fan
> servir alguna heurística.
> 
> Utilitzem un servidor per fer els càlculs, i hem trobat (òbviament)
> variacions significatives que depenen de la càrrega de la màquina. El
> què voler obtenir és un tipus de mesura independent de la càrrega del
> servidor.
> 
> Un enfocament ha estat utilitzar el temps de CPU. En el nostre cas, el
> nombre total dels segons de CPU que el procés utilitza directament (en
> mode d'usuari). No estem parlant del temps real transcorregut (wall
> clock) que òbviament és directament està afectat per la càrrega de la
> màquina.
> 
> No obstant això, hem realitzat diverses proves i hem descobert que té
> una variació al voltant del 10% (depenent de la càrrega). També hem
> avaluat el temps de CPU en mode kernel i també com hi ha un canvi de
> context perquè l'aplicació no s'executa. Però, sincerament no hem
> obtingut una idea clara del que està passant.
> 
> Una altra qüestió que hem trobat és com pot afectar el nombre de nuclis.
> o CPUs físiques al servidor.
> 
> Algú de vosaltres ha trobat aquests problemes i els ha resolt?
> 
> 
> Salutacions,
> 
> Leopold
> 

Re: consulta unattended-upgrades

[Jordi]

El dc. 02 de 06 de 2021 a les 07:36 +, en/na xavi va escriure:
> Hola,
> 
> No sé si aquesta pregunta vorejaria l'offtopic, però per si de cas us
> la 
> faig. A la feina i fins i tot a casa, a totes les meves màquines
> debian 
> i ubuntu faig servir sempre unattended-upgrades. Particularment en 
> aquelles que tenen accés a l'exterior (servidors i tal). Per mi és
> una 
> eina d'actualització de seguretat ràpida i potent. Però estic llegint
> a 
> grups de Telegram, i en alguna opinió d'algun company, que 
> unattended-upgrades mai, que les actualitzacions a mà.
> 
> No acabo d'entendre què tenen en contra, que no se'ls hi actualitzin 
> programes que tinguin extremadíssimament configurats a mà i que
> tinguin 
> por que una actualització els aixafi la configuració prèvia? o que
> fent 
> servir unattended-upgrades un podria arribar a confiar-se en excés i 
> prefereixen anar actualitzant a mà? (aquest últim argument per mi
> seria 
> del nivell com no voler fer servir el wifi perquè com que te'l poden 
> crackejar).
> 
> Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per 
> això voldria saber les vostres opinions, aviam què opineu :)
> 
> Records i gràcies per endavant.
> 
> x.
> 
La meva opinió: trobo que si les coses es fan massa automàticament, en
perds una mica el control. Jo abans em trobava que algunes coses no
funcionaven com ho havien fet fins cert moment i és perquè alguna cosa
s'havia actualitzat i alguna petita cosa funcionava de forma diferent.
Els programes tampoc han d'estar "extremadíssimament configurats"
perquè quelcom paràmetre deixi de funcionar o hi hagi nous paràmetres
que facin coses noves. I això sense parlar d'actualitzacions prou
importants ... Per això soc partidari de que el sistema m'avisi si hi
ha actualitzacions però soc jo qui decideix quan fer-les.

salutacions

Jordi.

consulta unattended-upgrades

[xavi]

Hola,

No sé si aquesta pregunta vorejaria l'offtopic, però per si de cas us la 
faig. A la feina i fins i tot a casa, a totes les meves màquines debian 
i ubuntu faig servir sempre unattended-upgrades. Particularment en 
aquelles que tenen accés a l'exterior (servidors i tal). Per mi és una 
eina d'actualització de seguretat ràpida i potent. Però estic llegint a 
grups de Telegram, i en alguna opinió d'algun company, que 
unattended-upgrades mai, que les actualitzacions a mà.


No acabo d'entendre què tenen en contra, que no se'ls hi actualitzin 
programes que tinguin extremadíssimament configurats a mà i que tinguin 
por que una actualització els aixafi la configuració prèvia? o que fent 
servir unattended-upgrades un podria arribar a confiar-se en excés i 
prefereixen anar actualitzant a mà? (aquest últim argument per mi seria 
del nivell com no voler fer servir el wifi perquè com que te'l poden 
crackejar).


Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per 
això voldria saber les vostres opinions, aviam què opineu :)


Records i gràcies per endavant.

x.

Re: Mesurar rendiment d'una aplicació

[Josep Lladonosa]

El dc., 2 de juny 2021, 8:14, Leopold Palomo-Avellaneda 
va escriure:

> El 1/6/21 a les 23:00, Àlex ha escrit:
> > Aquí hi ha diferents de codi per mesurar temps d'us de cpu (cpu time) i
> > el temps total (wall time). A tu t'interessa el cpu time:
> >
> >
> https://levelup.gitconnected.com/8-ways-to-measure-execution-time-in-c-c-48634458d0f9
> >
> >
> Genial!!!
>
> Però és una passada perquè el CPU time hauria de ser més o menys constant
> i no
> ho és. Nosaltres hem trobat variacions de fins al un 10%.
>

Hola, Leo,

Has aportat una pregunta molt interessant. Si més no m'hi has fet rumiar
una bona estona.

Podria ser que la causa de les variacions sigui la temperatura?

Els nuclis dels processadors redueixen la freqüència dels nuclis quan la
temperatura baixa.

https://www.pugetsystems.com/labs/articles/Impact-of-Temperature-on-Intel-CPU-Performance-606/

SALUT!



> Leo
>
> --
> --
> Linux User 152692 GPG: 05F4A7A949A2D9AA
> Catalonia
> -
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
>

Re: Mesurar rendiment d'una aplicació

[Leopold Palomo-Avellaneda]

El 1/6/21 a les 23:00, Àlex ha escrit:

Aquí hi ha diferents de codi per mesurar temps d'us de cpu (cpu time) i
el temps total (wall time). A tu t'interessa el cpu time:

https://levelup.gitconnected.com/8-ways-to-measure-execution-time-in-c-c-48634458d0f9



Genial!!!

Però és una passada perquè el CPU time hauria de ser més o menys constant i no 
ho és. Nosaltres hem trobat variacions de fins al un 10%.


Leo

--
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?