czwartek, stycznia 25, 2018
Ubuntu 17.10 window buttons like in Unity
gsettings set org.gnome.desktop.wm.preferences button-layout 'close,minimize,maximize:'
środa, stycznia 17, 2018
poniedziałek, stycznia 08, 2018
Bridges and slow consumer
Here what happens when we bridge standard communication to one slowly consumed topic: data store grows and becomes fragmented causing additional delay in EMS processing. It will be especially visible in SAP request-reply activities:
niedziela, stycznia 07, 2018
Google is going to win with Amazon
This year I visited Amazon Gdansk. I also bought Amazon Alexa Echo Dot and did black box testing and analysis of possible Alexa design. I spent about 6 hours learning organization and verifying my assumptions about Alexa (much more hacking round speaker). Do you remember Google Chrome based on KDE's KHTML starting with single digit marker share? Now Google browser is a leader. I didn't believe in Amazon success.
Understanding Tibco BW Checkpoint
BW Checkpoint activity writes BW JobData to disk or database. In case BW process is killed engine can read file or database entry and resume from saved JobData. When BW process finishes checkpoint data is deleted. It is important to understand function of this activity. It helps to preserve input volatile data and prevent duplicates. Please notice that pattern JMS Queue Receive + Send used with acknowledge mode = Client produces duplicates. Acknowledge mode local transactional works only in simple scenarios and cannot be applied to every possible combination of BW activities. Transactional JMS processing in BW is possible with XA, however XA is buggy. So the simplest pattern to prevent duplicates in 99% is checkpoint.
When you process important data in BW and target system is not idempotent, you cannot pass duplicates.
Let's get back to Checkpoint activity. It can be implemented with filesystem or database. In case of high volume of concurrent large messages database is under heavy load with clob data: "INSERT INTO $table(job_id, engine_name, job_data) VALUES (?,?,?)". However to prevent duplicates in active-active deployment database is the only option to not lock data in failed BW instance. What about file implementation? It uses FileOutputStream with close() and without OS fsync() via FileChannel.force(). Java close() method does not call underlying OS close() immediately but only via Java finalizer. Only force() gives strong consistency guaranty: If this channel's file resides on a local storage device then when this method returns it is guaranteed that all changes made to the file since this channel was created, or since this method was last invoked, will have been written to that device. This is useful for ensuring that critical information is not lost in the event of a system crash. There is engine property bw.engine.checkpoint.file.besteffortsync causing 2 phase checkpointing (save to file and rename). Please check Tibco Support knowledge base:
BW 5.3.3 hf14, BW 5.6.1
1-8H96WT
An empty checkpoint data file was created if the system crashed or
shutdown abruptly while checkpoint data was being written to the
file. It may result in messages being lost. This is fixed by
introducing a new engine property,
'bw.engine.checkpoint.file.besteffortsync'. By default, the property
is set to false. Setting this property to true addresses the problem,
but introduces a performance delay.
In Linux file memory buffers are flushed to disk every 5 seconds. Please consult https://www.kernel.org/doc/Documentation/sysctl/vm.txt:
dirty_writeback_centisecs
The kernel flusher threads will periodically wake up and write `old' data
out to disk. This tunable expresses the interval between those wakeups, in
100'ths of a second.
Setting this to zero disables periodic writeback altogether.
BW jobs which end sooner that 5s from checkpoint do not write to disk any data. Long running processes write files using Linux IO scheduler optimizations (deadline, cfq). To summarize: BW file checkpoint on Linux is not a serious performance problem when used wisely.
When you process important data in BW and target system is not idempotent, you cannot pass duplicates.
Let's get back to Checkpoint activity. It can be implemented with filesystem or database. In case of high volume of concurrent large messages database is under heavy load with clob data: "INSERT INTO $table(job_id, engine_name, job_data) VALUES (?,?,?)". However to prevent duplicates in active-active deployment database is the only option to not lock data in failed BW instance. What about file implementation? It uses FileOutputStream with close() and without OS fsync() via FileChannel.force(). Java close() method does not call underlying OS close() immediately but only via Java finalizer. Only force() gives strong consistency guaranty: If this channel's file resides on a local storage device then when this method returns it is guaranteed that all changes made to the file since this channel was created, or since this method was last invoked, will have been written to that device. This is useful for ensuring that critical information is not lost in the event of a system crash. There is engine property bw.engine.checkpoint.file.besteffortsync causing 2 phase checkpointing (save to file and rename). Please check Tibco Support knowledge base:
BW 5.3.3 hf14, BW 5.6.1
1-8H96WT
An empty checkpoint data file was created if the system crashed or
shutdown abruptly while checkpoint data was being written to the
file. It may result in messages being lost. This is fixed by
introducing a new engine property,
'bw.engine.checkpoint.file.besteffortsync'. By default, the property
is set to false. Setting this property to true addresses the problem,
but introduces a performance delay.
In Linux file memory buffers are flushed to disk every 5 seconds. Please consult https://www.kernel.org/doc/Documentation/sysctl/vm.txt:
dirty_writeback_centisecs
The kernel flusher threads will periodically wake up and write `old' data
out to disk. This tunable expresses the interval between those wakeups, in
100'ths of a second.
Setting this to zero disables periodic writeback altogether.
BW jobs which end sooner that 5s from checkpoint do not write to disk any data. Long running processes write files using Linux IO scheduler optimizations (deadline, cfq). To summarize: BW file checkpoint on Linux is not a serious performance problem when used wisely.
środa, stycznia 03, 2018
Danfoss Eco firmware reader
https://www.pjrc.com/teensy/beta/DDI0403D_arm_architecture_v7m_reference_manual.pdf
http://www.cypress.com/file/198301/download
http://www.cypress.com/products/psoc-4-ble-bluetooth-smart
https://sourceware.org/cgen/gen-doc/arm-thumb-insn.html
arm-none-eabi-objdump -D -bbinary -marm v1.13.cyacd.bin -Mforce-thumb | less
http://www.cypress.com/file/198301/download
http://www.cypress.com/products/psoc-4-ble-bluetooth-smart
https://sourceware.org/cgen/gen-doc/arm-thumb-insn.html
arm-none-eabi-objdump -D -bbinary -marm v1.13.cyacd.bin -Mforce-thumb | less
wtorek, stycznia 02, 2018
Danfoss Eco
Gdyby grzejniki w mieszkaniu były takie mądre, żeby same zmniejszyły temperaturę na noc, a potem nagrzały pokój tuż przed wstawaniem do pracy. Żeby po wyjściu do pracy grzejniki ustawiały się same na 17C. A w sobotę i niedzielę, żeby grzały później niż w dni robocze. Żeby można było stworzyć harmonogram na cały tydzień. Można. Są na rynku termostaty Danfoss Eco programowane z komórki za pomocą protokołu Bluetooth.
Jak to może działać? Temperaturowy zakres pracy urządzenia to 0-40C. Rodzielczość pół stopnia. Pomiary temperatury co 10 minut, a ustawianie co 30 minut. Tablica do adaptacji może wyglądać tak: czas [0-48], T zadana, T początkowa, T wynikowa, l - długość po obwodzie wykręcenie zaworu. Urządzenie sprawdza czy dla danego czasu i zadanej temperatury ma wpis. Jeśli tak to sprawdza T początkową. Jeśli są takie same to sprawdza T wynikową. Jeśli wartość wynikowa równa się zadanej to używa historycznej wartości l. Jeśli wartość wynikowa jest większa l musi być mniejsze, w przeciwnym wypadku większe. Po upływie cyklu 30 minut urządzenie zapisuje aktualne parametry. Temperatury i wartość l dadzą się zapisać w 8 bitach, a cały wpis tablicy na 32-bitowej liczbie całkowitej, dlatego liniowe skanowanie tablicy w celu znalezienia najlepszego wpisu [T zadana, T początkowa] jest szybkie. Mikrokontroler może być bardzo prosty. Stos Bluetooth może jednak wymagać SoC ARM.
 |
| Na dole temperatura z harmonogramu lub ustawiona ręcznie (i obowiązująca do następnej zmiany automatycznej), na górze temperatura zmierzona przez termostat. |
 |
| Aktualnie widoczne po protokole Bluetooth termostaty. Zasięg komunikacji wynosi do 10m. |
 |
| Adaptive learning pozwala na uczenie się termostatu jak bardzo ma odkręcić zawór, żeby uzyskać docelową temperaturę. Po 7 dniach termostat powinien optymalnie utrzymywać zadane wartości. W przypadku otwartego salonu i/lub grzejnika w pobliżu drzwi balkonowych kontrolę ciepła (Heat control) należy ustawić na Moderate (vs Quick) - nagrzane powietrze szybko ucieka i należy założyć większą bezwładność wynikową grzejnika. |
 |
| Gdzie są domyślne temperatury? Z prawej strony ekranu. Trzeba wykonać ruch slide. |
Jak to może działać? Temperaturowy zakres pracy urządzenia to 0-40C. Rodzielczość pół stopnia. Pomiary temperatury co 10 minut, a ustawianie co 30 minut. Tablica do adaptacji może wyglądać tak: czas [0-48], T zadana, T początkowa, T wynikowa, l - długość po obwodzie wykręcenie zaworu. Urządzenie sprawdza czy dla danego czasu i zadanej temperatury ma wpis. Jeśli tak to sprawdza T początkową. Jeśli są takie same to sprawdza T wynikową. Jeśli wartość wynikowa równa się zadanej to używa historycznej wartości l. Jeśli wartość wynikowa jest większa l musi być mniejsze, w przeciwnym wypadku większe. Po upływie cyklu 30 minut urządzenie zapisuje aktualne parametry. Temperatury i wartość l dadzą się zapisać w 8 bitach, a cały wpis tablicy na 32-bitowej liczbie całkowitej, dlatego liniowe skanowanie tablicy w celu znalezienia najlepszego wpisu [T zadana, T początkowa] jest szybkie. Mikrokontroler może być bardzo prosty. Stos Bluetooth może jednak wymagać SoC ARM.
Subskrybuj:
Posty (Atom)
