ELOG Midas

Back Midas Rome Roody Rootana

Midas DAQ System, Page 59 of 150

Not logged in

Find | Login | Help

Full | Summary | Threaded | Hide attachments

2994 Entries

Goto page Previous 1, 2, 3 ... 58, 59, 60 ... 148, 149, 150 Next

ID	Date	Author	Topic	Subject
2928	02 Jan 2025	Pavel Murat	Forum	time ordering of run transition calls to TMFeEquipment things
Hi K.O., your clarification is much appreciated! " > I am not sure what you are trying to do. It is always easier to suggest a solution to a specific problem. I think, I owe you an explanation :) : Consider ~ 40 nodes with two FPGAs (PCIE cards) per node, talking to the detector hardware. One of those FPGAs, in addition to reading the data, performs the global timing synchronization. The high-bandwidth data readout is not controlled by MIDAS, so all frontends perform only 'slow control'-type functions. In MIDAS language, an FPGA implements two different units of slow control equipment: one - configuring and controlling a single FPGA (equipment type A), and another one - synchronizing multiple FPGAs (equipment type B). On one of the nodes, unit A and unit B share the FPGA card, so they better be controlled by the same frontend. For one, I need to make sure that all type A equipment units, managed by multiple frontends, are initialized before the [single] type B unit which shares the frontend with the type A unit. And, of course, the end of a run transition has to be handled in the opposite order - type B unit shuts down first. As 'periodic' actions for all registered pieces of equipment are performed in the same loop [thread], registering the equipment in the needed order - first A, then B - should give a solution - thanks for making that clear. > > 1) "time ordering of run transitions" - of course midas transitions are ordered by transition sequence numbers > and the tmfe class provides methods to control this. ditto for the mfe.cxx frontends. > > 2) for one TMFrontend, the order of calling HandleBeginRun() is the order in which equipments were added to the > equipment using FeAddEquipment(). HandleEndRun() is called in reverse order. (I better check this). the ordering of the rpc handler calls in tmfe's tr_stop/tr_pause/tr_resume functions is ok. > > 3) to have multiple TMFrontends in one program would be unusual (mfe.cxx frontends completely do not support > this), but should work. Everything was coded to support this, but it was never tested in practice because we > cannot invent any useful use-case for it. HandleBeginRun() handlers are likely to be called in the frontends are > created. (I could check this and confirm it works, as long as you have a valid use-case for this configuration). agreed, I don't think there is a good use case for that, so no need to spend time checking. > > 4) Frontend X has EquipmentA and EquipmentB, you want EqA::HandleBeginRun() to be called at run transition 200 > and EqB::HandleBeginRun() to be called at run transition 400. > > This is not directly supported by mfe.cxx frontends (the begin_run() handler is a global function) and I did not > directly implement it in the TMFE frontend. > > But I think this would be a useful improvement. I will look into this. In the simplest case, registering the equipment units in the right order is definitely the answer. However a single FPGA can perform multiple logically independent tasks and thus represent multiple logical units of equipment. Those units however are not independent: they share the hardware (FPGA) and thus do depend on each other. Giving users a full control over the sequence in which those logical units execute their run transitions is quite likely to be needed, for example, to work around peculiarities of the custom-made kernel drivers. > > Likely I will add per-equipment data members fEqConfBeginRunSeqNo, fEqConfEndRunSeqno, etc. Value 0 would > unregister the corresponding run transition handler. This would cleanup the code quite a bit, a bunch > of RegisterTranstionXXX functions could go away. this also makes sense. -- thanks again, regards, Pasha > > K.O.
2932	18 Jan 2025	Pavel Murat	Forum	mjsonrpc: how to increase the max allowed length of the callback response ?
Dear MIDAS experts, I'm using MIDAS javascript interface (mjsonrpc) to communicate with a frontend from a custom web page and observe that the if the frontend's response exceeds certain number of bytes, it is always truncated. MIDAS C/C++ RPC interface allows users to specify the max response length : https://daq00.triumf.ca/MidasWiki/index.php/Remote_Procedure_Calls_(RPC)#C++_2 How would one do the same from with mjsonrpc ? -- many thanks, regards, Pasha
2934	30 Jan 2025	Pavel Murat	Forum	converting non-MIDAS slow control data into MIDAS history format ?
Dear MIDAS experts, I have a time series of slow control measurements in an ASCII format - data records in a format (run_number, time, temperature, voltage1, ..., voltageN), and, if possible, would like to convert them into a MIDAS history format. Making MIDAS events out of that data is easy, but is it possible to preserve the time stamps? - Logically, this boils down to whether it is possible to have the event time set by a user frontend -- as always - many thanks, regards, Pasha
2935	31 Jan 2025	Pavel Murat	Forum	converting non-MIDAS slow control data into MIDAS history format ?
I think I found an answer to my question: a user-controlled event header does have a time stamp: https://daq00.triumf.ca/MidasWiki/index.php/Event_Structure#Event_Header -- apologies for the spam, regards, Pasha
2936	01 Feb 2025	Pavel Murat	Bug Report	MIDAS history system not using the event timestamps ?
> I have a time series of slow control measurements in an ASCII format - > data records in a format (run_number, time, temperature, voltage1, ..., voltageN), > and, if possible, would like to convert them into a MIDAS history format. > > Making MIDAS events out of that data is easy, but is it possible to preserve > the time stamps? - Logically, this boils down to whether it is possible to have > the event time set by a user frontend It looks that the original question was not as naive as I expected and may be pointing to a subtle bug. I have implemented a python frontend - essentially a clone of https://bitbucket.org/tmidas/midas/src/develop/python/midas/frontend.py reading the old slow control data and setting the event.header.timestamp's to some dates from the year of 2022. When I run MIDAS and read the "old slow control events", one event in 10 seconds, the MIDAS Event Dump utility shows the data with the correct event timestamps, from the year of 2022. However the history plots show the event parameters with the timestamps from Feb 01 2025 and the adjacent data points separated by 10 sec. Is it possible that the history system uses its own timestamp setting instead of using timestamps from the event headers? - Under normal circumstances, the two should be very close, and that could've kept the issue hidden... -- thanks, regards, Pasha UPDATE: I attached the frontend code and the input data file it is reading. The data file should reside in the local directory - the frontend code doesn't have everything fully automated for the test, -- an integer field "/Mu2e/Offline/Ops/LastTime" would need to be created manually -- the history plots would need to be declared manually
Attachment 1: test_frontend.py
#!/usr/bin/env python """ Example of a basic midas frontend that has one periodic equipment. See `examples/multi_frontend.py` for an example that uses more features (frontend index, polled equipment, ODB settings etc). """ import midas import midas.frontend import midas.event import time, os, sys from datetime import datetime #import TRACE #TRACE_NAME = 'test_frontend.py' class MyPeriodicEquipment(midas.frontend.EquipmentBase): """ We define an "equipment" for each logically distinct task that this frontend performs. For example, you may have one equipment for reading data from a device and sending it to a midas buffer, and another equipment that updates summary statistics every 10s. Each equipment class you define should inherit from `midas.frontend.EquipmentBase`, and should define a `readout_func` function. If you're creating a "polled" equipment (rather than a periodic one), you should also define a `poll_func` function in addition to `readout_func`. """ def __init__(self, client): # The name of our equipment. This name will be used on the midas status # page, and our info will appear in /Equipment/MyPeriodicEquipment in # the ODB. equip_name = "MyPeriodicEquipment" # Define the "common" settings of a frontend. These will appear in # /Equipment/MyPeriodicEquipment/Common. The values you set here are # only used the very first time this frontend/equipment runs; after # that the ODB settings are used. default_common = midas.frontend.InitialEquipmentCommon() default_common.equip_type = midas.EQ_PERIODIC default_common.buffer_name = "SYSTEM" default_common.trigger_mask = 0 default_common.event_id = 1 default_common.period_ms = 100 default_common.read_when = midas.RO_ALWAYS default_common.log_history = 1 # You MUST call midas.frontend.EquipmentBase.__init__ in your equipment's __init__ method! midas.frontend.EquipmentBase.__init__(self, client, equip_name, default_common) # You can set the status of the equipment (appears in the midas status page) self.set_status("Initialized") self._verbose = 1; # --------------------------------------------------------------------- def Print(self,Name,level,Message): if(level>self._verbose): return 0; now = time.strftime('%Y/%m/%d %H:%M:%S',time.localtime(time.time())) message = now+' [ GridSubmit::'+Name+' ] '+Message print(message) def readout_func(self): """ For a periodic equipment, this function will be called periodically (every 100ms in this case). It should return either a `cdms.event.Event` or None (if we shouldn't write an event). """ last_time = self.client.odb_get('/Mu2e/Offline/Ops/LastTime') self.Print('readout_func',1,f'last_time:{last_time}') # cmd = 'dqmTool print-numbers --source 5 --value 6 --expand' cmd = 'cat val_nightly.csv' self.Print('readout_func',1,'executing cmd:%s'%cmd) out=os.popen(cmd).readlines() event = None; for line in out: # print(line) words = line.strip().split(',') #------------------------------------------------------------------------------ # ['91', '5228', '0.0', '0 5', 'valNightly', 'reco', 'day', '0 6', 'ops', 'stats', 'CPU 11', '4', '0', '0', '0', '0', '2022-01-11 00:01:00-06:00', '2022-01-11 00:01:00-06:00'] #------------------------------------------------------------------------------ # In this example, we just make a simple event with one bank. dt = datetime.strptime(words[17], "%Y-%m-%d %H:%M:%S%z"); ts = dt.timestamp(); if (ts > last_time) : data = [] print(words); event = midas.event.Event() data.append(float(words[0])); data.append(float(words[1])); data.append(float(words[2])); event.create_bank("OFLN", midas.TID_FLOAT, data) event.header.timestamp = int(ts); self.client.odb_set('/Mu2e/Offline/Ops/LastTime',ts) print(f'SET_NEW last_time:{ts} dt:{dt}') # self.Print('readout_func',1,f'SET_NEW last_time:{ts} dt:{dt}') break; return event class MyFrontend(midas.frontend.FrontendBase): """ A frontend contains a collection of equipment. You can access self.client to access the ODB etc (see `midas.client.MidasClient`). """ def __init__(self): # You must call __init__ from the base class. midas.frontend.FrontendBase.__init__(self, "myfe_name") # You can add equipment at any time before you call `run()`, but doing # it in __init__() seems logical. self.add_equipment(MyPeriodicEquipment(self.client)) self._verbose = 1 def begin_of_run(self, run_number): """ This function will be called at the beginning of the run. You don't have to define it, but you probably should. You can access individual equipment classes through the `self.equipment` dict if needed. """ self.set_all_equipment_status("Running", "greenLight") self.client.msg("Frontend has seen start of run number %d" % run_number) return midas.status_codes["SUCCESS"] def end_of_run(self, run_number): self.set_all_equipment_status("Finished", "greenLight") self.client.msg("Frontend has seen end of run number %d" % run_number) return midas.status_codes["SUCCESS"] def frontend_exit(self): """ Most people won't need to define this function, but you can use it for final cleanup if needed. """ print("Goodbye from user code!") if __name__ == "__main__": # The main executable is very simple - just create the frontend object, # and call run() on it. print("EMOE"); # TRACE.TRACE(7,'EMOEM',TRACE_NAME) with MyFrontend() as my_fe: my_fe.run()
Attachment 2: val_nightly.csv
21,4219,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 6,4,0,0,0,0,2022-01-06 00:01:00-06:00,2022-01-06 00:01:00-06:00 35,4999,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 7,4,0,0,0,0,2022-01-07 00:01:00-06:00,2022-01-07 00:01:00-06:00 49,4187,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 8,4,0,0,0,0,2022-01-08 00:01:00-06:00,2022-01-08 00:01:00-06:00 63,3875,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 9,4,0,0,0,0,2022-01-09 00:01:00-06:00,2022-01-09 00:01:00-06:00 77,4498,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 10,4,0,0,0,0,2022-01-10 00:01:00-06:00,2022-01-10 00:01:00-06:00 91,5228,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 11,4,0,0,0,0,2022-01-11 00:01:00-06:00,2022-01-11 00:01:00-06:00 105,4682,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 12,4,0,0,0,0,2022-01-12 00:01:00-06:00,2022-01-12 00:01:00-06:00 119,4364,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 13,4,0,0,0,0,2022-01-13 00:01:00-06:00,2022-01-13 00:01:00-06:00 133,5069,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 14,4,0,0,0,0,2022-01-14 00:01:00-06:00,2022-01-14 00:01:00-06:00 147,3848,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 15,4,0,0,0,0,2022-01-15 00:01:00-06:00,2022-01-15 00:01:00-06:00 161,5248,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 16,4,0,0,0,0,2022-01-16 00:01:00-06:00,2022-01-16 00:01:00-06:00 175,5276,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 17,4,0,0,0,0,2022-01-17 00:01:00-06:00,2022-01-17 00:01:00-06:00 189,5089,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 18,4,0,0,0,0,2022-01-18 00:01:00-06:00,2022-01-18 00:01:00-06:00 203,4789,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 19,4,0,0,0,0,2022-01-19 00:01:00-06:00,2022-01-19 00:01:00-06:00 217,4652,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 20,4,0,0,0,0,2022-01-20 00:01:00-06:00,2022-01-20 00:01:00-06:00 232,5343,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 23,5,0,0,0,0,2022-01-21 00:01:00-06:00,2022-01-21 00:01:00-06:00 246,4896,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 30,5,0,0,0,0,2022-01-22 00:01:00-06:00,2022-01-22 00:01:00-06:00 296,4812,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 46,5,0,0,0,0,2022-01-23 00:01:00-06:00,2022-01-23 00:01:00-06:00 310,4994,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 53,5,0,0,0,0,2022-01-24 00:01:00-06:00,2022-01-24 00:01:00-06:00 324,4397,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 60,5,0,0,0,0,2022-01-25 00:01:00-06:00,2022-01-25 00:01:00-06:00 338,5242,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 67,5,0,0,0,0,2022-01-26 00:01:00-06:00,2022-01-26 00:01:00-06:00 352,4915,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 74,5,0,0,0,0,2022-01-27 00:01:00-06:00,2022-01-27 00:01:00-06:00 366,4937,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 81,5,0,0,0,0,2022-01-28 00:01:00-06:00,2022-01-28 00:01:00-06:00 380,5096,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 88,5,0,0,0,0,2022-01-29 00:01:00-06:00,2022-01-29 00:01:00-06:00 394,5139,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 95,5,0,0,0,0,2022-01-30 00:01:00-06:00,2022-01-30 00:01:00-06:00 408,5434,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 102,5,0,0,0,0,2022-01-31 00:01:00-06:00,2022-01-31 00:01:00-06:00 422,5212,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 109,5,0,0,0,0,2022-02-01 00:01:00-06:00,2022-02-01 00:01:00-06:00 436,5144,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 116,5,0,0,0,0,2022-02-02 00:01:00-06:00,2022-02-02 00:01:00-06:00 450,4229,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 123,5,0,0,0,0,2022-02-03 00:01:00-06:00,2022-02-03 00:01:00-06:00 464,4760,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 130,5,0,0,0,0,2022-02-04 00:01:00-06:00,2022-02-04 00:01:00-06:00 478,4770,0.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 137,5,0,0,0,0,2022-02-05 00:01:00-06:00,2022-02-05 00:01:00-06:00 492,5171,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 144,5,0,0,0,0,2022-02-06 00:01:00-06:00,2022-02-06 00:01:00-06:00 650,4740,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 153,5,0,0,0,0,2022-02-10 00:01:00-06:00,2022-02-10 00:01:00-06:00 700,4923,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 160,5,0,0,0,0,2022-02-11 00:01:00-06:00,2022-02-11 00:01:00-06:00 750,0.0,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 167,5,0,0,0,0,2022-02-12 00:01:00-06:00,2022-02-12 00:01:00-06:00 800,0.0,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 174,5,0,0,0,0,2022-02-13 00:01:00-06:00,2022-02-13 00:01:00-06:00 850,4250,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 181,5,0,0,0,0,2022-02-14 00:01:00-06:00,2022-02-14 00:01:00-06:00 900,4668,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 188,5,0,0,0,0,2022-02-15 00:01:00-06:00,2022-02-15 00:01:00-06:00 950,4638,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 195,5,0,0,0,0,2022-02-16 00:01:00-06:00,2022-02-16 00:01:00-06:00 1000,5111,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 202,5,0,0,0,0,2022-02-17 00:01:00-06:00,2022-02-17 00:01:00-06:00 1050,3788,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 209,5,0,0,0,0,2022-02-18 00:01:00-06:00,2022-02-18 00:01:00-06:00 1100,5291,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 216,5,0,0,0,0,2022-02-19 00:01:00-06:00,2022-02-19 00:01:00-06:00 1150,4563,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 223,5,0,0,0,0,2022-02-20 00:01:00-06:00,2022-02-20 00:01:00-06:00 1200,4649,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 230,5,0,0,0,0,2022-02-21 00:01:00-06:00,2022-02-21 00:01:00-06:00 1250,0.0,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 237,5,0,0,0,0,2022-02-22 00:01:00-06:00,2022-02-22 00:01:00-06:00 1300,0.0,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 244,5,0,0,0,0,2022-02-23 00:01:00-06:00,2022-02-23 00:01:00-06:00 1350,0.0,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 251,5,0,0,0,0,2022-02-24 00:01:00-06:00,2022-02-24 00:01:00-06:00 1400,0.0,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 258,5,0,0,0,0,2022-02-25 00:01:00-06:00,2022-02-25 00:01:00-06:00 1450,0.0,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 265,5,0,0,0,0,2022-02-26 00:01:00-06:00,2022-02-26 00:01:00-06:00 1500,0.0,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 272,5,0,0,0,0,2022-02-27 00:01:00-06:00,2022-02-27 00:01:00-06:00 1550,0.0,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 279,5,0,0,0,0,2022-02-28 00:01:00-06:00,2022-02-28 00:01:00-06:00 1600,254,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 286,5,0,0,0,0,2022-03-01 00:01:00-06:00,2022-03-01 00:01:00-06:00 1650,203,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 293,5,0,0,0,0,2022-03-02 00:01:00-06:00,2022-03-02 00:01:00-06:00 1700,259,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 300,5,0,0,0,0,2022-03-03 00:01:00-06:00,2022-03-03 00:01:00-06:00 1750,255,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 307,5,0,0,0,0,2022-03-04 00:01:00-06:00,2022-03-04 00:01:00-06:00 1800,259,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 314,5,0,0,0,0,2022-03-05 00:01:00-06:00,2022-03-05 00:01:00-06:00 1850,284,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 321,5,0,0,0,0,2022-03-06 00:01:00-06:00,2022-03-06 00:01:00-06:00 1900,258,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 328,5,0,0,0,0,2022-03-07 00:01:00-06:00,2022-03-07 00:01:00-06:00 1950,284,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 335,5,0,0,0,0,2022-03-08 00:01:00-06:00,2022-03-08 00:01:00-06:00 2000,220,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 342,5,0,0,0,0,2022-03-09 00:01:00-06:00,2022-03-09 00:01:00-06:00 2050,197,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 349,5,0,0,0,0,2022-03-10 00:01:00-06:00,2022-03-10 00:01:00-06:00 2100,263,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 356,5,0,0,0,0,2022-03-11 00:01:00-06:00,2022-03-11 00:01:00-06:00 2150,283,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 363,5,0,0,0,0,2022-03-12 00:01:00-06:00,2022-03-12 00:01:00-06:00 2200,276,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 370,5,0,0,0,0,2022-03-13 00:01:00-06:00,2022-03-13 00:01:00-06:00 2250,212,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 377,5,0,0,0,0,2022-03-14 00:01:00-05:00,2022-03-14 00:01:00-05:00 2300,255,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 384,5,0,0,0,0,2022-03-15 00:01:00-05:00,2022-03-15 00:01:00-05:00 2350,212,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 391,5,0,0,0,0,2022-03-16 00:01:00-05:00,2022-03-16 00:01:00-05:00 2400,231,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 398,5,0,0,0,0,2022-03-17 00:01:00-05:00,2022-03-17 00:01:00-05:00 2450,209,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 405,5,0,0,0,0,2022-03-18 00:01:00-05:00,2022-03-18 00:01:00-05:00 2500,253,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 412,5,0,0,0,0,2022-03-19 00:01:00-05:00,2022-03-19 00:01:00-05:00 2550,233,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 419,5,0,0,0,0,2022-03-20 00:01:00-05:00,2022-03-20 00:01:00-05:00 2600,1661,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 426,5,0,0,0,0,2022-03-21 00:01:00-05:00,2022-03-21 00:01:00-05:00 2650,1940,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 433,5,0,0,0,0,2022-03-22 00:01:00-05:00,2022-03-22 00:01:00-05:00 2700,1177,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 440,5,0,0,0,0,2022-03-23 00:01:00-05:00,2022-03-23 00:01:00-05:00 2750,1537,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 447,5,0,0,0,0,2022-03-24 00:01:00-05:00,2022-03-24 00:01:00-05:00 2800,1908,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 454,5,0,0,0,0,2022-03-25 00:01:00-05:00,2022-03-25 00:01:00-05:00 2850,1290,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 461,5,0,0,0,0,2022-03-26 00:01:00-05:00,2022-03-26 00:01:00-05:00 2900,1286,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 468,5,0,0,0,0,2022-03-27 00:01:00-05:00,2022-03-27 00:01:00-05:00 2950,1944,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 475,5,0,0,0,0,2022-03-28 00:01:00-05:00,2022-03-28 00:01:00-05:00 3000,1365,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 482,5,0,0,0,0,2022-03-29 00:01:00-05:00,2022-03-29 00:01:00-05:00 3050,1252,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 489,5,0,0,0,0,2022-03-30 00:01:00-05:00,2022-03-30 00:01:00-05:00 3100,2010,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 496,5,0,0,0,0,2022-03-31 00:01:00-05:00,2022-03-31 00:01:00-05:00 3150,1998,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 503,5,0,0,0,0,2022-04-01 00:01:00-05:00,2022-04-01 00:01:00-05:00 3200,1342,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 510,5,0,0,0,0,2022-04-02 00:01:00-05:00,2022-04-02 00:01:00-05:00 3250,2158,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 517,5,0,0,0,0,2022-04-03 00:01:00-05:00,2022-04-03 00:01:00-05:00 3300,2033,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 524,5,0,0,0,0,2022-04-04 00:01:00-05:00,2022-04-04 00:01:00-05:00 3350,1935,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 531,5,0,0,0,0,2022-04-05 00:01:00-05:00,2022-04-05 00:01:00-05:00 3400,1860,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 538,5,0,0,0,0,2022-04-06 00:01:00-05:00,2022-04-06 00:01:00-05:00 3450,1279,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 545,5,0,0,0,0,2022-04-07 00:01:00-05:00,2022-04-07 00:01:00-05:00 3500,1340,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 552,5,0,0,0,0,2022-04-08 00:01:00-05:00,2022-04-08 00:01:00-05:00 3550,1746,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 559,5,0,0,0,0,2022-04-09 00:01:00-05:00,2022-04-09 00:01:00-05:00 3600,1312,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 566,5,0,0,0,0,2022-04-10 00:01:00-05:00,2022-04-10 00:01:00-05:00 3650,1802,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 573,5,0,0,0,0,2022-04-11 00:01:00-05:00,2022-04-11 00:01:00-05:00 3700,1997,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 580,5,0,0,0,0,2022-04-12 00:01:00-05:00,2022-04-12 00:01:00-05:00 3750,1657,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 587,5,0,0,0,0,2022-04-13 00:01:00-05:00,2022-04-13 00:01:00-05:00 3800,1684,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 594,5,0,0,0,0,2022-04-14 00:01:00-05:00,2022-04-14 00:01:00-05:00 3850,1811,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 601,5,0,0,0,0,2022-04-15 00:01:00-05:00,2022-04-15 00:01:00-05:00 3900,1959,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 608,5,0,0,0,0,2022-04-16 00:01:00-05:00,2022-04-16 00:01:00-05:00 3950,1501,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 615,5,0,0,0,0,2022-04-17 00:01:00-05:00,2022-04-17 00:01:00-05:00 4000,1434,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 622,5,0,0,0,0,2022-04-18 00:01:00-05:00,2022-04-18 00:01:00-05:00 4050,1286,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 629,5,0,0,0,0,2022-04-19 00:01:00-05:00,2022-04-19 00:01:00-05:00 4100,1598,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 636,5,0,0,0,0,2022-04-20 00:01:00-05:00,2022-04-20 00:01:00-05:00 4150,1747,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 643,5,0,0,0,0,2022-04-21 00:01:00-05:00,2022-04-21 00:01:00-05:00 4200,1254,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 650,5,0,0,0,0,2022-04-22 00:01:00-05:00,2022-04-22 00:01:00-05:00 4250,2049,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 657,5,0,0,0,0,2022-04-23 00:01:00-05:00,2022-04-23 00:01:00-05:00 4300,1905,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 664,5,0,0,0,0,2022-04-24 00:01:00-05:00,2022-04-24 00:01:00-05:00 4350,1423,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 671,5,0,0,0,0,2022-04-25 00:01:00-05:00,2022-04-25 00:01:00-05:00 4400,2151,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 678,5,0,0,0,0,2022-04-26 00:01:00-05:00,2022-04-26 00:01:00-05:00 4450,2005,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 685,5,0,0,0,0,2022-04-28 00:01:00-05:00,2022-04-28 00:01:00-05:00 4500,1831,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 692,5,0,0,0,0,2022-04-29 00:01:00-05:00,2022-04-29 00:01:00-05:00 4550,1820,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 699,5,0,0,0,0,2022-04-30 00:01:00-05:00,2022-04-30 00:01:00-05:00 4600,1827,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 706,5,0,0,0,0,2022-05-01 00:01:00-05:00,2022-05-01 00:01:00-05:00 4650,1891,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 713,5,0,0,0,0,2022-05-02 00:01:00-05:00,2022-05-02 00:01:00-05:00 4700,1265,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 720,5,0,0,0,0,2022-05-03 00:01:00-05:00,2022-05-03 00:01:00-05:00 4750,2047,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 727,5,0,0,0,0,2022-05-04 00:01:00-05:00,2022-05-04 00:01:00-05:00 4800,1646,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 734,5,0,0,0,0,2022-05-05 00:01:00-05:00,2022-05-05 00:01:00-05:00 4850,1940,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 741,5,0,0,0,0,2022-05-06 00:01:00-05:00,2022-05-06 00:01:00-05:00 4900,1831,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 748,5,0,0,0,0,2022-05-07 00:01:00-05:00,2022-05-07 00:01:00-05:00 4950,1217,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 755,5,0,0,0,0,2022-05-08 00:01:00-05:00,2022-05-08 00:01:00-05:00 5000,1623,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 762,5,0,0,0,0,2022-05-09 00:01:00-05:00,2022-05-09 00:01:00-05:00 5050,1183,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 769,5,0,0,0,0,2022-05-10 00:01:00-05:00,2022-05-10 00:01:00-05:00 5100,1702,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 776,5,0,0,0,0,2022-05-11 00:01:00-05:00,2022-05-11 00:01:00-05:00 5150,1623,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 783,5,0,0,0,0,2022-05-12 00:01:00-05:00,2022-05-12 00:01:00-05:00 5200,1328,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 790,5,0,0,0,0,2022-05-13 00:01:00-05:00,2022-05-13 00:01:00-05:00 5250,1530,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 797,5,0,0,0,0,2022-05-14 00:01:00-05:00,2022-05-14 00:01:00-05:00 5300,1792,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 804,5,0,0,0,0,2022-05-15 00:01:00-05:00,2022-05-15 00:01:00-05:00 5350,1989,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 811,5,0,0,0,0,2022-05-16 00:01:00-05:00,2022-05-16 00:01:00-05:00 5400,1723,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 818,5,0,0,0,0,2022-05-17 00:01:00-05:00,2022-05-17 00:01:00-05:00 5450,1740,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 825,5,0,0,0,0,2022-05-18 00:01:00-05:00,2022-05-18 00:01:00-05:00 5500,1822,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 832,5,0,0,0,0,2022-05-19 00:01:00-05:00,2022-05-19 00:01:00-05:00 5550,1812,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 839,5,0,0,0,0,2022-05-20 00:01:00-05:00,2022-05-20 00:01:00-05:00 5600,1310,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 846,5,0,0,0,0,2022-05-21 00:01:00-05:00,2022-05-21 00:01:00-05:00 5650,1574,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 853,5,0,0,0,0,2022-05-22 00:01:00-05:00,2022-05-22 00:01:00-05:00 5700,1371,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 860,5,0,0,0,0,2022-05-23 00:01:00-05:00,2022-05-23 00:01:00-05:00 5750,1822,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 867,5,0,0,0,0,2022-05-24 00:01:00-05:00,2022-05-24 00:01:00-05:00 5800,1375,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 874,5,0,0,0,0,2022-05-25 00:01:00-05:00,2022-05-25 00:01:00-05:00 5850,1737,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 881,5,0,0,0,0,2022-05-26 00:01:00-05:00,2022-05-26 00:01:00-05:00 5900,1407,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 888,5,0,0,0,0,2022-05-27 00:01:00-05:00,2022-05-27 00:01:00-05:00 5950,2086,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 895,5,0,0,0,0,2022-05-28 00:01:00-05:00,2022-05-28 00:01:00-05:00 6000,1937,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 902,5,0,0,0,0,2022-05-29 00:01:00-05:00,2022-05-29 00:01:00-05:00 6050,1145,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 909,5,0,0,0,0,2022-05-30 00:01:00-05:00,2022-05-30 00:01:00-05:00 6100,1588,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 916,5,0,0,0,0,2022-05-31 00:01:00-05:00,2022-05-31 00:01:00-05:00 6150,1775,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 923,5,0,0,0,0,2022-06-01 00:01:00-05:00,2022-06-01 00:01:00-05:00 6200,1083,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 930,5,0,0,0,0,2022-06-02 00:01:00-05:00,2022-06-02 00:01:00-05:00 6250,1914,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 937,5,0,0,0,0,2022-06-03 00:01:00-05:00,2022-06-03 00:01:00-05:00 6300,1789,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 944,5,0,0,0,0,2022-06-04 00:01:00-05:00,2022-06-04 00:01:00-05:00 6350,1231,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 951,5,0,0,0,0,2022-06-05 00:01:00-05:00,2022-06-05 00:01:00-05:00 6400,1848,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 958,5,0,0,0,0,2022-06-06 00:01:00-05:00,2022-06-06 00:01:00-05:00 6450,1907,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 965,5,0,0,0,0,2022-06-07 00:01:00-05:00,2022-06-07 00:01:00-05:00 6500,2039,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 972,5,0,0,0,0,2022-06-08 00:01:00-05:00,2022-06-08 00:01:00-05:00 6550,1972,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 979,5,0,0,0,0,2022-06-09 00:01:00-05:00,2022-06-09 00:01:00-05:00 6600,1816,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 986,5,0,0,0,0,2022-06-10 00:01:00-05:00,2022-06-10 00:01:00-05:00 6650,1983,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 993,5,0,0,0,0,2022-06-11 00:01:00-05:00,2022-06-11 00:01:00-05:00 6700,1695,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1000,5,0,0,0,0,2022-06-12 00:01:00-05:00,2022-06-12 00:01:00-05:00 6750,1762,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1007,5,0,0,0,0,2022-06-13 00:01:00-05:00,2022-06-13 00:01:00-05:00 6800,1828,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1014,5,0,0,0,0,2022-06-14 00:01:00-05:00,2022-06-14 00:01:00-05:00 6850,1911,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1021,5,0,0,0,0,2022-06-15 00:01:00-05:00,2022-06-15 00:01:00-05:00 6900,1690,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1028,5,0,0,0,0,2022-06-16 00:01:00-05:00,2022-06-16 00:01:00-05:00 6950,1895,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1035,5,0,0,0,0,2022-06-17 00:01:00-05:00,2022-06-17 00:01:00-05:00 7000,2086,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1042,5,0,0,0,0,2022-06-23 00:01:00-05:00,2022-06-23 00:01:00-05:00 7050,1775,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1049,5,0,0,0,0,2022-06-24 00:01:00-05:00,2022-06-24 00:01:00-05:00 7100,1992,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1056,5,0,0,0,0,2022-06-25 00:01:00-05:00,2022-06-25 00:01:00-05:00 7150,1435,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1063,5,0,0,0,0,2022-06-26 00:01:00-05:00,2022-06-26 00:01:00-05:00 7200,1273,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1070,5,0,0,0,0,2022-06-27 00:01:00-05:00,2022-06-27 00:01:00-05:00 7250,2321,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1077,5,0,0,0,0,2022-06-28 00:01:00-05:00,2022-06-28 00:01:00-05:00 7300,1666,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1084,5,0,0,0,0,2022-06-29 00:01:00-05:00,2022-06-29 00:01:00-05:00 7350,1598,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1091,5,0,0,0,0,2022-06-30 00:01:00-05:00,2022-06-30 00:01:00-05:00 7400,2090,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1098,5,0,0,0,0,2022-07-01 00:01:00-05:00,2022-07-01 00:01:00-05:00 7450,2066,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1105,5,0,0,0,0,2022-07-02 00:01:00-05:00,2022-07-02 00:01:00-05:00 7500,1253,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1112,5,0,0,0,0,2022-07-03 00:01:00-05:00,2022-07-03 00:01:00-05:00 7550,1367,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1119,5,0,0,0,0,2022-07-04 00:01:00-05:00,2022-07-04 00:01:00-05:00 7600,1737,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1126,5,0,0,0,0,2022-07-05 00:01:00-05:00,2022-07-05 00:01:00-05:00 7650,2065,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1133,5,0,0,0,0,2022-07-06 00:01:00-05:00,2022-07-06 00:01:00-05:00 7700,2065,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1140,5,0,0,0,0,2022-07-07 00:01:00-05:00,2022-07-07 00:01:00-05:00 7750,1548,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1147,5,0,0,0,0,2022-07-08 00:01:00-05:00,2022-07-08 00:01:00-05:00 7800,1849,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1154,5,0,0,0,0,2022-07-09 00:01:00-05:00,2022-07-09 00:01:00-05:00 7850,1175,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1161,5,0,0,0,0,2022-07-10 00:01:00-05:00,2022-07-10 00:01:00-05:00 7900,1430,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1168,5,0,0,0,0,2022-07-11 00:01:00-05:00,2022-07-11 00:01:00-05:00 7950,1716,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1175,5,0,0,0,0,2022-07-12 00:01:00-05:00,2022-07-12 00:01:00-05:00 8000,1854,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1182,5,0,0,0,0,2022-07-13 00:01:00-05:00,2022-07-13 00:01:00-05:00 8050,1338,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1189,5,0,0,0,0,2022-07-14 00:01:00-05:00,2022-07-14 00:01:00-05:00 8100,1474,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1196,5,0,0,0,0,2022-07-15 00:01:00-05:00,2022-07-15 00:01:00-05:00 8150,0.0,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1203,5,0,0,0,0,2022-07-16 00:01:00-05:00,2022-07-16 00:01:00-05:00 8200,1288,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1210,5,0,0,0,0,2022-07-17 00:01:00-05:00,2022-07-17 00:01:00-05:00 8250,1784,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1217,5,0,0,0,0,2022-07-18 00:01:00-05:00,2022-07-18 00:01:00-05:00 8300,1981,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1224,5,0,0,0,0,2022-07-19 00:01:00-05:00,2022-07-19 00:01:00-05:00 8350,1332,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1231,5,0,0,0,0,2022-07-20 00:01:00-05:00,2022-07-20 00:01:00-05:00 8400,1680,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1238,5,0,0,0,0,2022-07-21 00:01:00-05:00,2022-07-21 00:01:00-05:00 8450,1384,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1245,5,0,0,0,0,2022-07-22 00:01:00-05:00,2022-07-22 00:01:00-05:00 8500,1929,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1252,5,0,0,0,0,2022-07-23 00:01:00-05:00,2022-07-23 00:01:00-05:00 8550,1994,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1259,5,0,0,0,0,2022-07-24 00:01:00-05:00,2022-07-24 00:01:00-05:00 8600,1976,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1266,5,0,0,0,0,2022-07-25 00:01:00-05:00,2022-07-25 00:01:00-05:00 8650,1719,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1273,5,0,0,0,0,2022-07-26 00:01:00-05:00,2022-07-26 00:01:00-05:00 8700,1752,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1280,5,0,0,0,0,2022-07-27 00:01:00-05:00,2022-07-27 00:01:00-05:00 8750,1264,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1287,5,0,0,0,0,2022-07-28 00:01:00-05:00,2022-07-28 00:01:00-05:00 8800,1649,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1294,5,0,0,0,0,2022-07-29 00:01:00-05:00,2022-07-29 00:01:00-05:00 8850,1656,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1301,5,0,0,0,0,2022-07-30 00:01:00-05:00,2022-07-30 00:01:00-05:00 8900,1283,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1308,5,0,0,0,0,2022-07-31 00:01:00-05:00,2022-07-31 00:01:00-05:00 8950,1242,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1315,5,0,0,0,0,2022-08-01 00:01:00-05:00,2022-08-01 00:01:00-05:00 9000,1586,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1322,5,0,0,0,0,2022-08-02 00:01:00-05:00,2022-08-02 00:01:00-05:00 9050,1396,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1329,5,0,0,0,0,2022-08-03 00:01:00-05:00,2022-08-03 00:01:00-05:00 9100,2035,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1336,5,0,0,0,0,2022-08-04 00:01:00-05:00,2022-08-04 00:01:00-05:00 9150,1774,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1343,5,0,0,0,0,2022-08-05 00:01:00-05:00,2022-08-05 00:01:00-05:00 9200,1878,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1350,5,0,0,0,0,2022-08-06 00:01:00-05:00,2022-08-06 00:01:00-05:00 9250,1922,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1357,5,0,0,0,0,2022-08-07 00:01:00-05:00,2022-08-07 00:01:00-05:00 9300,2277,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1364,5,0,0,0,0,2022-08-08 00:01:00-05:00,2022-08-08 00:01:00-05:00 9350,1589,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1371,5,0,0,0,0,2022-08-09 00:01:00-05:00,2022-08-09 00:01:00-05:00 9400,0.0,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1378,5,0,0,0,0,2022-08-10 00:01:00-05:00,2022-08-10 00:01:00-05:00 9450,1689,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1385,5,0,0,0,0,2022-08-11 00:01:00-05:00,2022-08-11 00:01:00-05:00 9500,1995,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1392,5,0,0,0,0,2022-08-12 00:01:00-05:00,2022-08-12 00:01:00-05:00 9514,0.0,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1399,5,0,0,0,0,2022-08-13 00:01:00-05:00,2022-08-13 00:01:00-05:00 9564,1247,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1406,5,0,0,0,0,2022-08-14 00:01:00-05:00,2022-08-14 00:01:00-05:00 9614,1614,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1413,5,0,0,0,0,2022-08-15 00:01:00-05:00,2022-08-15 00:01:00-05:00 9664,1489,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1420,5,0,0,0,0,2022-08-16 00:01:00-05:00,2022-08-16 00:01:00-05:00 9714,1330,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1427,5,0,0,0,0,2022-08-17 00:01:00-05:00,2022-08-17 00:01:00-05:00 9764,1289,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1434,5,0,0,0,0,2022-08-18 00:01:00-05:00,2022-08-18 00:01:00-05:00 9814,1877,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1441,5,0,0,0,0,2022-08-19 00:01:00-05:00,2022-08-19 00:01:00-05:00 9864,1271,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1448,5,0,0,0,0,2022-08-20 00:01:00-05:00,2022-08-20 00:01:00-05:00 9923,1753,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1455,5,0,0,0,0,2022-08-21 00:01:00-05:00,2022-08-21 00:01:00-05:00 9974,1372,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1463,5,0,0,0,0,2022-08-22 00:01:00-05:00,2022-08-22 00:01:00-05:00 10025,1308,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1471,5,0,0,0,0,2022-08-23 00:01:00-05:00,2022-08-23 00:01:00-05:00 10076,1240,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1479,5,0,0,0,0,2022-08-24 00:01:00-05:00,2022-08-24 00:01:00-05:00 10127,1837,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1487,5,0,0,0,0,2022-08-25 00:01:00-05:00,2022-08-25 00:01:00-05:00 10178,1422,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1495,5,0,0,0,0,2022-08-26 00:01:00-05:00,2022-08-26 00:01:00-05:00 10229,1281,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1503,5,0,0,0,0,2022-08-27 00:01:00-05:00,2022-08-27 00:01:00-05:00 10280,1449,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1511,5,0,0,0,0,2022-08-28 00:01:00-05:00,2022-08-28 00:01:00-05:00 10331,1258,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1519,5,0,0,0,0,2022-08-29 00:01:00-05:00,2022-08-29 00:01:00-05:00 10382,1521,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1527,5,0,0,0,0,2022-08-30 00:01:00-05:00,2022-08-30 00:01:00-05:00 10433,1794,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1535,5,0,0,0,0,2022-08-31 00:01:00-05:00,2022-08-31 00:01:00-05:00 10484,1020,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1543,5,0,0,0,0,2022-09-01 00:01:00-05:00,2022-09-01 00:01:00-05:00 10535,1141,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1551,5,0,0,0,0,2022-09-02 00:01:00-05:00,2022-09-02 00:01:00-05:00 10586,1060,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1559,5,0,0,0,0,2022-09-03 00:01:00-05:00,2022-09-03 00:01:00-05:00 10637,1579,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1567,5,0,0,0,0,2022-09-04 00:01:00-05:00,2022-09-04 00:01:00-05:00 10688,961,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1575,5,0,0,0,0,2022-09-05 00:01:00-05:00,2022-09-05 00:01:00-05:00 10739,1251,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1583,5,0,0,0,0,2022-09-06 00:01:00-05:00,2022-09-06 00:01:00-05:00 10790,1748,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1591,5,0,0,0,0,2022-09-07 00:01:00-05:00,2022-09-07 00:01:00-05:00 10841,1475,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1599,5,0,0,0,0,2022-09-08 00:01:00-05:00,2022-09-08 00:01:00-05:00 10892,1229,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1607,5,0,0,0,0,2022-09-09 00:01:00-05:00,2022-09-09 00:01:00-05:00 10943,1082,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1615,5,0,0,0,0,2022-09-10 00:01:00-05:00,2022-09-10 00:01:00-05:00 10994,1768,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1623,5,0,0,0,0,2022-09-11 00:01:00-05:00,2022-09-11 00:01:00-05:00 11045,1111,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1631,5,0,0,0,0,2022-09-12 00:01:00-05:00,2022-09-12 00:01:00-05:00 11096,1221,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1639,5,0,0,0,0,2022-09-13 00:01:00-05:00,2022-09-13 00:01:00-05:00 11147,1649,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1647,5,0,0,0,0,2022-09-14 00:01:00-05:00,2022-09-14 00:01:00-05:00 11198,1565,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1655,5,0,0,0,0,2022-09-15 00:01:00-05:00,2022-09-15 00:01:00-05:00 11249,1492,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1663,5,0,0,0,0,2022-09-16 00:01:00-05:00,2022-09-16 00:01:00-05:00 11300,1215,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1671,5,0,0,0,0,2022-09-17 00:01:00-05:00,2022-09-17 00:01:00-05:00 11351,990,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1679,5,0,0,0,0,2022-09-18 00:01:00-05:00,2022-09-18 00:01:00-05:00 11402,1220,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1687,5,0,0,0,0,2022-09-19 00:01:00-05:00,2022-09-19 00:01:00-05:00 11453,1737,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1695,5,0,0,0,0,2022-09-20 00:01:00-05:00,2022-09-20 00:01:00-05:00 11504,1786,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1703,5,0,0,0,0,2022-09-21 00:01:00-05:00,2022-09-21 00:01:00-05:00 11555,1658,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1711,5,0,0,0,0,2022-09-22 00:01:00-05:00,2022-09-22 00:01:00-05:00 11606,1580,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1719,5,0,0,0,0,2022-09-23 00:01:00-05:00,2022-09-23 00:01:00-05:00 11657,1003,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1727,5,0,0,0,0,2022-09-24 00:01:00-05:00,2022-09-24 00:01:00-05:00 11708,1630,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1735,5,0,0,0,0,2022-09-25 00:01:00-05:00,2022-09-25 00:01:00-05:00 11759,1535,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1743,5,0,0,0,0,2022-09-26 00:01:00-05:00,2022-09-26 00:01:00-05:00 11810,1242,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1751,5,0,0,0,0,2022-09-27 00:01:00-05:00,2022-09-27 00:01:00-05:00 11861,1601,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1759,5,0,0,0,0,2022-09-28 00:01:00-05:00,2022-09-28 00:01:00-05:00 11912,1831,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1767,5,0,0,0,0,2022-09-29 00:01:00-05:00,2022-09-29 00:01:00-05:00 11963,1830,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1775,5,0,0,0,0,2022-09-30 00:01:00-05:00,2022-09-30 00:01:00-05:00 12014,1819,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1783,5,0,0,0,0,2022-10-01 00:01:00-05:00,2022-10-01 00:01:00-05:00 12065,1533,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1791,5,0,0,0,0,2022-10-02 00:01:00-05:00,2022-10-02 00:01:00-05:00 12116,1663,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1799,5,0,0,0,0,2022-10-03 00:01:00-05:00,2022-10-03 00:01:00-05:00 12167,1513,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1807,5,0,0,0,0,2022-10-04 00:01:00-05:00,2022-10-04 00:01:00-05:00 12218,1235,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1815,5,0,0,0,0,2022-10-05 00:01:00-05:00,2022-10-05 00:01:00-05:00 12269,1385,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1823,5,0,0,0,0,2022-10-06 00:01:00-05:00,2022-10-06 00:01:00-05:00 12320,1521,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1831,5,0,0,0,0,2022-10-07 00:01:00-05:00,2022-10-07 00:01:00-05:00 12371,1613,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1839,5,0,0,0,0,2022-10-08 00:01:00-05:00,2022-10-08 00:01:00-05:00 12422,1282,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1847,5,0,0,0,0,2022-10-09 00:01:00-05:00,2022-10-09 00:01:00-05:00 12473,1174,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1855,5,0,0,0,0,2022-10-10 00:01:00-05:00,2022-10-10 00:01:00-05:00 12524,1511,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1863,5,0,0,0,0,2022-10-11 00:01:00-05:00,2022-10-11 00:01:00-05:00 12575,1510,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1871,5,0,0,0,0,2022-10-12 00:01:00-05:00,2022-10-12 00:01:00-05:00 12626,1110,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1879,5,0,0,0,0,2022-10-13 00:01:00-05:00,2022-10-13 00:01:00-05:00 12677,1107,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1887,5,0,0,0,0,2022-10-14 00:01:00-05:00,2022-10-14 00:01:00-05:00 12728,1129,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1895,5,0,0,0,0,2022-10-15 00:01:00-05:00,2022-10-15 00:01:00-05:00 12779,1194,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1903,5,0,0,0,0,2022-10-16 00:01:00-05:00,2022-10-16 00:01:00-05:00 12830,1028,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1911,5,0,0,0,0,2022-10-17 00:01:00-05:00,2022-10-17 00:01:00-05:00 12881,1036,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1919,5,0,0,0,0,2022-10-18 00:01:00-05:00,2022-10-18 00:01:00-05:00 12932,1160,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1927,5,0,0,0,0,2022-10-19 00:01:00-05:00,2022-10-19 00:01:00-05:00 12983,1488,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1935,5,0,0,0,0,2022-10-20 00:01:00-05:00,2022-10-20 00:01:00-05:00 13034,1693,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1943,5,0,0,0,0,2022-10-21 00:01:00-05:00,2022-10-21 00:01:00-05:00 13085,1658,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1951,5,0,0,0,0,2022-10-22 00:01:00-05:00,2022-10-22 00:01:00-05:00 13136,1130,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1959,5,0,0,0,0,2022-10-23 00:01:00-05:00,2022-10-23 00:01:00-05:00 13187,1623,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1967,5,0,0,0,0,2022-10-24 00:01:00-05:00,2022-10-24 00:01:00-05:00 13238,1528,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1975,5,0,0,0,0,2022-10-25 00:01:00-05:00,2022-10-25 00:01:00-05:00 13289,1714,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1983,5,0,0,0,0,2022-10-26 00:01:00-05:00,2022-10-26 00:01:00-05:00 13340,1441,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1991,5,0,0,0,0,2022-10-28 00:01:00-05:00,2022-10-28 00:01:00-05:00 13391,1478,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 1999,5,0,0,0,0,2022-10-29 00:01:00-05:00,2022-10-29 00:01:00-05:00 13442,1346,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 2007,5,0,0,0,0,2022-10-30 00:01:00-05:00,2022-10-30 00:01:00-05:00 13493,1568,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 2015,5,0,0,0,0,2022-10-31 00:01:00-05:00,2022-10-31 00:01:00-05:00 13544,1076,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 2023,5,0,0,0,0,2022-11-01 00:01:00-05:00,2022-11-01 00:01:00-05:00 13595,1462,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 2031,5,0,0,0,0,2022-11-02 00:01:00-05:00,2022-11-02 00:01:00-05:00 13646,1365,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 2039,5,0,0,0,0,2022-11-03 00:01:00-05:00,2022-11-03 00:01:00-05:00 13697,1491,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 2047,5,0,0,0,0,2022-11-04 00:01:00-05:00,2022-11-04 00:01:00-05:00 13748,1486,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 2055,5,0,0,0,0,2022-11-05 00:01:00-05:00,2022-11-05 00:01:00-05:00 13799,1576,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 2063,5,0,0,0,0,2022-11-06 00:01:00-05:00,2022-11-06 00:01:00-05:00 13850,1121,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 2071,5,0,0,0,0,2022-11-07 00:01:00-06:00,2022-11-07 00:01:00-06:00 13901,0.0,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 2079,5,0,0,0,0,2022-11-08 00:01:00-06:00,2022-11-08 00:01:00-06:00 13952,1401,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 2087,5,0,0,0,0,2022-11-09 00:01:00-06:00,2022-11-09 00:01:00-06:00 14003,1099,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 2095,5,0,0,0,0,2022-11-10 00:01:00-06:00,2022-11-10 00:01:00-06:00 14054,1134,150.0,0 5,valNightly,reco,day,0 6,ops,stats,CPU 2103,5,0,0,0,0,2022-11-11 00:01:00-06:00,2022-11-11 00:01:00-06:00 ... 783 more lines ...
3012	01 Apr 2025	Pavel Murat	Bug Report	MIDAS history system not using the event timestamps ?
Dear MIDAS experts, I confirm that when writing out history files corresponding to the slow control event data, MIDAS history system timestamps the data not with the event time coming from the event data, but with the current time determined by the program - https://bitbucket.org/tmidas/midas/src/293d27fad0c87c80c4ed7b94b5c40ba1e150bea4/progs/mlogger.cxx#lines-5321 where 'now' is defined as time_t now = time(NULL); I'm looking for a way to timestamp the history data with the event time - that is important for HEP applications outside the DAQ domain. Yes, MIDAS infrastructure is very well suited for that, there could have a number of such applications, and experiments could significantly benefit from that. So I'm wondering whether the implementation is a design choice made or it could be changed. The change itself and especially its validation may require a non-negligible amount of work - I'd be happy to contribute. Any insight much appreciated. -- thanks, regards, Pasha
3021	01 Apr 2025	Pavel Murat	Suggestion	Sequencer ODBSET feature requests
I once looked at using LUA for this, > but I think basing off an full featured programming language like python > is better. if it came to a vote, my vote would go to Lua: it would allow to do everything needed, with much less external dependencies and with much less motivation to over-use the interpreter. The CMS experience was very teaching in this respect... -- my 2c, regards, Pasha
3022	02 Apr 2025	Pavel Murat	Bug Report	MIDAS history system not using the event timestamps ?
> You can always include your "true" data timestamp as the first value in your data. Are you saying that if the first data word of a history event were a timestamp, the MIDAS history system, when plotting the time dependencies, would use that timestamp instead of the mlogger timestamp? if that is true, what tells MIDAS that the first data word is the timestamp? I couldn't find a discussion of that on the page describing the history system - https://daq00.triumf.ca/MidasWiki/index.php/History_System#Frontend_history_event - perhaps I should be looking at a different page? -- thanks again, regards, Pasha
80	09 Dec 2003	Paul Knowles		db_close_record non-local/non-return
Hi All, I have found a weird one: The following code executes on the frontend machine in the frontend_exit() routine, and connects to the odb running on another separate machine: ... cm_msg(MINFO,__func__, "line %d", __LINE__); cm_get_experiment_database(&hdb, NULL); cm_msg(MINFO,__func__, "line %d", __LINE__); status = db_find_key(hdb, 0, "/Experiment/Run Parameters", &hkey); cm_msg(MINFO,__func__, "line %d, hkey=%d, status=%d", __LINE__, hkey, status); checkstat("db_find_key returned status %d", status); cm_msg(MINFO,__func__, "line %d", __LINE__); status = db_close_record(hdb, hkey); /* NOTREACHED!! the above call to db_close_record doesn't return! */ cm_msg(MINFO,__func__, "line %d, status=%d", __LINE__, status); checkstat("db_close_record returned status %d", status); checkstat is a macro that does the following: #define checkstat(format, arg...)\ do{ if(status != DB_SUCCESS) {\ cm_msg(MERROR, __func__, format, ## arg);\ return FE_ERR_ODB;}}while(0) The key exists, and the status of the search is 1 (i.e., DB_SUCCESS) and rest of the code tries to run. What gets really weird is that the db_close_record _doesn't_ _return_. The code following the NOTREACHED comment just doesn't get called. I get the message from the __LINE__ just in front of the call, but not the message afterwards (cm_msg and printf were tried). Somehow db_close_record is causing a non-local exit or signal or something. No error message is printed and the frontend continues to exit with exit code 0. But, since the rest of my frontend_exit/odb closing doesn't happen, the odb is left in a lost state requiring a cleanup. If I comment out the calls to db_close_record, the rest of my frontend_exit runs normally and the cm_disconnect_experiment() in mfe.c eventually closes my open records correctly (I expect, anyway) and this is the present workaround i am using. The terror i have is that several of my hotlinked callback routines will call the close_record routine when resetting illegal values. No end of hilarity will result there... I was using the same code in the frontend under 1.9.2 and have only recently upgraded to 1.9.3-? tarball from PAA and there were no problems using the 1.9.2 code: this is a 1.9.3 issue. I have localized the weirdness to what I think is the RPC interface. Running the nullfrontend (no camac access) on the same machine as hosts the ODB I can make the problem appear and disappear in the following way: (odb is local on machine ``monet'') nullfe -h monet -e acqmonad : db_close_record will get lost nullfe -e acqmonad : db_close_record works as expected. I've tried also with the patch for the 256 byte odb string bug since many of the open records have strings of that length, but that isn't it. The only substancial looking change to mserver from 1.9.2 to 1.9.3 is the SIGPIPE ignore and that doesn't look like a good candidate either. Can this be that some of the #IFDEF LOCAL_ROUTINES that got moved about in odb.c and others are causing the remote call to get confused? Clearly the answer is to just use stable and happy 1.9.2, but the people for whom I am working now really want to use ROOT for an analyzer... cheers, .p. Paul Knowles. phone: 41 26 300 90 64 email: Paul.Knowles@unifr.ch Fax: 41 26 300 97 47 finger me at pexppc33.unifr.ch for more contact information
75	18 Dec 2003	Paul Knowles		Poll about default indent style
Hi Stefan, > once and forever, I am considering using the "indent" program which comes > with every linux installation. Running indent regularly on all our code > ensures a consistent look. I think this can be called a Good Thing. > The "-kr" style does the standard K&R style, > but used tabs (which is not good), and does a 4-column > indention which is I think too much. So I would propose > following flags: > indent -kr -nut -i2 -di8 -bad <filename.c> (some of this is a repeat from an earlier mail to SR): You might also want a -l90 for a longer line length than 75 characters. K&R style with indentation from 5 to 8 spaces is a good indicator of complexity: as soon as 40 characters of code wind up unreadably squashed to the right of the screen, you have to refactor to have less indentation levels. This means you wind up rolling up the inner parts of deeply nested conditionals or loops as separate functions, making the whole code easier to understand. I think that setting -i2 is ``going around the problem'' of deep nesting. If you really need to keep the indentation tabs less than 4 (8 is ideal) because your code is falling off the right edge of the screen, you are indented too deeply. Why do I say that? There is the famous ``7+-1'' idea that you can hold in you head only 7 ideas (give or take one) at any time. I'm not that smart and I top out at about 5: So for example, a conditional in a loop in a conditional in a switch is about as deep a level of nesting as I can easily understand (remember that I also have to hold the line i'm working on as well): that's 4 levels, plus one for the function itself and we are at 40 characters away from the right edge of the screen using -i8 and have some 40 characters available for writing code (how often is a line of code really longer than about 40 characters?). On top of that, the indentation is easily seen so you know immediately wheather you are at the upper conditional, or inner conditional. A -i2 just doesn't make the difference big enough. -i5 is a happy balance with enough visual clue as to the indentation level, but leaves you 50 to 60 characters for the code line itself. However, if you are indenting very deeply, then the poor reader can't hold on to the context: there are more than 6 or 7 things to keep in mind. In those cases, roll up the inner levels as a separate function and call it that way. The inner complexity of the nested statements gets nicely abstracted and then dumb people like me can understand what you are doing. So, in brief: indent is a good idea, and -in with n>=4 will be best. I don't think -i2 will lend itself to making the code so much easier to read. thanks for listening. .p.
1645	07 Aug 2019	Paolo Baesso	Bug Report	ROOTANA bug?
Hi, I posted on the ROOTANA elog but there seems to be little activity there... Could someone confirm if this is a bug? https://midas.triumf.ca/elog/Rootana/14 Another user replied that they are encountering the same issue, so I think it is unlikely it is just our installation. While ROOTANA is unusable for us, I tried to use the example Frontend and Analyzer (under the Experiment source folder). The analyzer does not seem to do much though. A root file is produced but nothing is placed into it. Is that normal? Any help would be welcome.
2775	21 May 2024	Nikolay	Bug Report	experiment from midas/examples
There are 2 bugs in midas/examples/experiment: 1) In fronted bank named "PRDC" is created for scaler event. But in analyzer module scaler.cxx the bank named "SCLR" is searched for the same event. 2) In mana.cxx linked from analyzer.cxx is "Invalid name "/Analyzer/Tests/Always true/Rate [Hz]" passed to db_create_key: should not contain "["". Looks like ODB doesn't like '[', ']' characters.
Attachment 1: analyzer.jpg

2500	02 May 2023	Niklaus Berger	Forum	Problem with running midas odbxx frontends on a remote machine using the -h option
Thanks for all the helpful hints. When finally managing to evade all timeouts and attach the debugger in just the right moment, we find that we get a segfault in mserver at L827: case RPC_DB_COPY_XML: status = db_copy_xml(CHNDLE(0), CHNDLE(1), CSTRING(2), CPINT(3), CBOOL(4)); Some printf debugging then pointed us to the fact that the culprit is the pointer de-referencing in CBOOL(4). This in turn can be traced back to mrpc.cxx L282 ff, where the line with the arrow was missing: {RPC_DB_COPY_XML, "db_copy_xml", {{TID_INT32, RPC_IN}, {TID_INT32, RPC_IN}, {TID_ARRAY, RPC_OUT \| RPC_VARARRAY}, {TID_INT32, RPC_IN \| RPC_OUT}, -> {TID_BOOL, RPC_IN}, {0}}}, If we put that in, the mserver process completes peacfully and we get a segfault in the client ("Wrong key type in XML file") which we will attempt to debug next. Shall I create a pull request for the additional RPC argument or will you just fix this on the fly?
2501	02 May 2023	Niklaus Berger	Forum	Problem with running midas odbxx frontends on a remote machine using the -h option
And now we also fixed the client segfault, odb.cxx L8992 also needs to know about the header: if (rpc_is_remote()) return rpc_call(RPC_DB_COPY_XML, hDB, hKey, buffer, buffer_size, header); (last argument was missing before).
1634	26 Jul 2019	Nik Berger	Bug Report	History/Endianness
Hi, I have a bank of floats with slow control values that I store to the history and ODB. When reading the history, both in the webbrowser and with mhist, the floats get read with the wrong endianness; under /equipment/variables in the ODB they however display correctly. System is a an intel OpenSuse linux box. Any ideas? Thanks Nik
1719	06 Oct 2019	Nik Berger	Bug Report	History data size mismatch
Logging a list of variables to the history via links in the history ODB subtree, we get messages as follows at every run start: 19:43:24.009 2019/10/06 [Logger,ERROR] [history_schema.cxx:2676:hs_write_event,ERROR] Event 'System' data size mismatch: expected 412 bytes, got 416 bytes 19:43:24.008 2019/10/06 [Logger,ERROR] [history_schema.cxx:2676:hs_write_event,ERROR] Event 'System' data size mismatch: expected 412 bytes, got 416 bytes 19:43:23.850 2019/10/06 [Logger,ERROR] [history_schema.cxx:455:hs_write_event,ERROR] Event 'System' data size mismatch count: 25, expected 412 bytes, hs_write_event() called with as much as 416 bytes 19:43:23.850 2019/10/06 [Logger,ERROR] [history_schema.cxx:455:hs_write_event,ERROR] Event 'System' data size mismatch count: 25, expected 412 bytes, hs_write_event() called with as much as 416 bytes The history calculates the size of a record from the size of the individual variables, (history_schema.cxx, L2666 ff), whereas the ODB delivers the data aligned/padded to the size of the largest value in the record. In our history, a long list of doubles (64 Bit) fas followed by three floats (32 bit), leading to a padded response from the ODB, 4 byte longer than the history expects. Quick fix: Add another 32 bit dummy variable to the history. Gets rid of the error messages... Should probably be fixed at a deeper level...
1722	10 Oct 2019	Nik Berger	Bug Report	History data size mismatch
>I wonder why do you this via ODB links. The "standard" way of writing to the history should be to create events for an equipment and flag this equipment as being written to the >history. All variables under /Equipment/<name>/Variables then automatically go into the history and you don't have to worry about ODB links. Only variables not fitting the >equipment/variables scheme should be dealt with via ODB links, like variables under equipment/statistics or parameters in another ODB tree. In a typical midas experiment, only >very few variables typically go into the 'System' event. This is however probably not a solution to your problem. If you have a similar structure (doubles plus an odd number of floats) >under 'variables', you might get the same error. > > In our history, a long list of doubles (64 Bit) fas followed by three floats (32 bit) > We do this in the MuX DAQ and mix things that come directly from MIDAS (the MIDAS trigger rate) and things from the analyzer (rates in the self-triggering detectors) and some temperatures from yet somewhere else. Yes, we could have kept that apart, yes, in this case a double would also work (and not break things), but a bug is a bug... I could think of senisble use cases where doubles and ints are mixed and I also know quite a few areas where it makes sense to use floats... Nik
1665	28 Aug 2019	Nick Hastings	Forum	History plot problems for frontend with multiple indicies
Hello experts, I have been writing a SC frontend for a powersupply. I have used the model where the frontend can be started with "-i n" option so that each fe can control a different supply. During the development/testing of the program I would normally only run a single instance with "-i 1". However when I started a second instance with "-i 2" I found problems with the history plots that were being made for the original "-i 1" instance. The variable being plotted seemed to randomly jump between the value from the "-i 1" instance and the "-i 2" instance. confirmed that the "correct" values exist for each frontend in the odb under /Equipment/Foo01/Variables and /Equipment/Foo02/Variables This is also not just a plotting artifact since I was also able to see the two different values by running mhist. I saw this behaviour using midas-2019-03 and also the head of the development branch (686e4de2b55023b0d1936c60bcf4767c5e6caac0 from just under 48 hours ago). I was able to reproduce this with a stripped down frontend that just sets a variable that is equal to its frontend_index. Please find the code and Makefile attached. Presumably I've done something wrong in my implementation that hopefully a more experienced person can spot quite quickly, but please let me know if any more information is needed. I have seen this behaviour on both Debian 10 and on a CentOS 7 Singularity image running on top of Debian 10. Thanks, Nick. P.S. I made the topic of this post "Forum" and not "Bug Report" since I expect the root of this problem is somewhere between the keyboard and chair.
Attachment 1: fedummy.cxx
/*****************************************************************\ Name: fetest.cxx Created by: Contents: Front end for testing MIDAS. Just sets a variable to the value of the frontend index. \*****************************************************************/ #undef NDEBUG // midas required assert() to be always enabled #include <cassert> #include "mfe.h" /-- Globals -------------------------------------------------------/ / The frontend name (client name) as seen by other MIDAS clients / const char frontend_name = "fedummy"; /* The frontend file name, don't change it / const char frontend_file_name = __FILE__; /* frontend_loop is called periodically if this variable is TRUE / BOOL frontend_call_loop = FALSE; / a frontend status page is displayed with this frequency in ms / INT display_period = 0; / maximum event size produced by this frontend / INT max_event_size = 410241024; INT max_event_size_frag = 410241024; / buffer size to hold events / INT event_buffer_size = 1010241024; /-- Function declarations -----------------------------------------/ INT frontend_init(); INT frontend_exit(); INT begin_of_run(INT run_number, char error); INT end_of_run(INT run_number, char error); INT pause_run(INT run_number, char error); INT resume_run(INT run_number, char error); INT frontend_loop(); INT poll_event(INT source, INT count, BOOL test); INT interrupt_configure(INT cmd, INT source, PTYPE adr); int read_dummy_event(char pevent, int off); /-- Equipment list ------------------------------------------------/ #ifndef FE_NAME #define FE_NAME "fedummy" #endif #ifndef EQ_NAME #define EQ_NAME "Dummy" #endif #ifndef EQ_EVID #define EQ_EVID 1 #endif char eq_name[256]; EQUIPMENT equipment[] = { { EQ_NAME "%02d" , /* equipment name / { EQ_EVID, (1<<EQ_EVID),/ event ID, trigger mask / "SYSTEM", / event buffer / EQ_PERIODIC, / equipment type / 0, / event source / "MIDAS", / format / TRUE, / enabled / RO_ALWAYS, / Read when running / 1000, / poll every so milliseconds / 0, / stop run after this event limit / 0, / number of sub events / 1, / history period / "", "", "" }, read_dummy_event,/ readout routine / NULL, NULL, NULL, / bank list / } , {""} }; int event_size = 101024; /-- Frontend Init -------------------------------------------------/ #include "msystem.h" INT frontend_init() { sprintf(eq_name, "%s%02d", EQ_NAME, get_frontend_index()); return SUCCESS; } INT frontend_exit() { return SUCCESS; } INT begin_of_run(INT run_number, char error) { return SUCCESS; } INT end_of_run(INT run_number, char error) { return SUCCESS; } INT pause_run(INT run_number, char error) { return SUCCESS; } INT resume_run(INT run_number, char error) { return SUCCESS; } INT frontend_loop() { return SUCCESS; } INT poll_event(INT source, INT count, BOOL test) { return 0; } INT interrupt_configure(INT cmd, INT source, PTYPE adr) { return 0; } INT read_dummy_event(char pevent, INT off) { static HNDLE hVar = 0; if ( hVar == 0 ) { char str[1024]; sprintf(str, "/Equipment/%s/Variables", eq_name); int status = db_find_key(hDB, 0, str, &hVar); if ( status == DB_NO_KEY ) { status = db_create_key(hDB, 0, str, TID_KEY); if (status == DB_SUCCESS) { status = db_find_key(hDB, 0, str, &hVar); } } if (status != SUCCESS) { cm_msg(MERROR, frontend_name, "read_dummy_event: Can\'t find or create %s, status %d, exiting", str, status); exit(1); } } const float data = static_cast<float>(get_frontend_index()); const int status = db_set_value( hDB, hVar, "Data", &data, sizeof(float), 1, TID_FLOAT); assert(status == DB_SUCCESS); return 0; } / emacs * Local Variables: * tab-width: 8 * c-basic-offset: 3 * indent-tabs-mode: nil * End: */
Attachment 2: Makefile
OSFLAGS = -DOS_LINUX -Dextname CFLAGS = -g -O2 -fPIC -Wall -Wno-unused-function -I$(MIDASSYS)/include CXXFLAGS = -std=c++11 $(CFLAGS) LIBS = -lm -lz -lutil -lnsl -lpthread -lrt MIDASLIBS = $(MIDASSYS)/lib/libmidas.a MFE = $(MIDASSYS)/lib/mfe.o all:: fedummy.exe fedummy.exe: %.exe: fedummy.cxx $(MIDASLIBS) $(MFE) $(CXX) -o $@ $(CXXFLAGS) $(OSFLAGS) $^ $(MIDASLIBS) $(LIBS) -DFE_NAME=\"fedummy\" -DEQ_NAME=\"FeDummy\" -DEQ_EVID=1 %.o: %.cxx $(CXX) $(CXXFLAGS) $(OSFLAGS) -c $< %.d: %.cxx $(CXX) -MM -MD $(CXXFLAGS) $(OSFLAGS) -c $< depend: -include .d clean:: -rm -f .o .exe -rm -f .d
1667	28 Aug 2019	Nick Hastings	Forum	History plot problems for frontend with multiple indicies
Hi Stefan, thanks for you quick reply. > My first question would be why are you using several font-ends at all? Becuase I was following the model used for many of the frontends for the ND280 FGD. > That makes things more > complicated than needed. In the normal FE framework, you can define either several equipment > served by one frontend, or even one equipment linked to several devices. In the MEG experiment > we have one slow control frontend controlling ~100 devices without problem. In the old days there > was a problem that some slow devices could throttle the readout, but since the invention of multi- > threaded slow control equipment, each device gets its own thread so they don't block each other. Perhaps things have changed in the 10 years since the FGD SC code was written. I can do it differently but doing it that way seemed naturual since around 90% of the frontend code that I have see does it that way. Nick.
Draft	29 Aug 2019	Nick Hastings	Forum	History plot problems for frontend with multiple indicies
Hi LCP, thanks for the suggestion and link. Unfortunatly I don't think this explains it. Nick.

Goto page Previous 1, 2, 3 ... 58, 59, 60 ... 148, 149, 150 Next

ELOG V3.1.4-2e1708b5