Attention is currently required from: laforge, pespin.
8 comments:
File include/osmocom/hnbgw/hnbgw.h:
Patch Set #6, Line 402: struct {
Oh I didn't mean joining the dl and ul. […]
yes i mean that too.
i wouldn't do it here because nothing points to it, but my opinion is not strong.
to keep it as is, resolve. to change it, say "change it please".
File src/osmo-hnbgw/hnbgw_hnbap.c:
Patch Set #6, Line 571: hnb_persistent_connected(ctx->persistent);
Can actually an HNB be registered without being connected? I don't think so. […]
yes, but a hnb can be connected without being registered. (that is for a different redmine ticket)
so do you prefer 'active' and 'inactive', or is 'connect' and 'disconnect' good enough.
File src/osmo-hnbgw/hnbgw_vty.c:
Patch Set #9, Line 894: vty_out(vty, "%% WARNING: nft configuration changes need a restart of osmo-hnbw%s", VTY_NEWLINE);
still a typo in here. osmo-hnbw.
hey! i fixed that!
File src/osmo-hnbgw/nft_kpi.c:
Patch Set #6, Line 86: static __thread struct nft_thread *g_nft_thread = NULL;
Ok, I'm not really a fan of having this sort of generic thread which may or may not do stuff, makes […]
Done
Patch Set #6, Line 193: static const char * const nft_thread_req_type_name[] = {
no. […]
i want to avoid iteration ala value_string, because all callers are entirely constants within this .c file
Patch Set #6, Line 415: static int update_ctr(struct rate_ctr_group *cg, int cgidx, uint64_t *last_val, uint64_t new_val)
Yes, after looking at the surrounding code. […]
kk
File src/osmo-hnbgw/nft_kpi.c:
Patch Set #9, Line 626: /* From here on, until we receive the next NFT_THREAD_GET_COUNTERS in this thread, the
Possible future improvement here is to use a double-buffer to fill next batch while the main thread […]
if ever the time it takes to retrieve counters does overlap the wait time configured in timer X34, then we would simply add another nft_counters2 thread, submitting GET_COUNTERS requests round robin between them. repeat to taste.
(but i don't expect that to be necessary.)
Patch Set #9, Line 994: nft_kpi_get_counters_schedule();
So you call nft_kpi_get_counters_schedule() once you receive + process the counters, which will then […]
i believe this was the result of our discussion: to wait X34 time *between* getting counters.
This is nice because it is simple and avoids all such races you describe.
What I don't like about it is that the metric from the user perspective should be "get timers every N seconds" -- when we wait in-between, we will "drift", elongating the period by the time it takes to retrieve counters.
This is not very long really, but i'd prefer scheduling to start counters every N seconds, not wait N seconds in-between.
Doing so means that we need to ensure avoiding races, making the code more complex.
So how ambitious are we? I think I am fine with waiting X34 seconds *between* getting counters. it is good enough as i see it.
Other opinions?
To view, visit change 36539. To unsubscribe, or for help writing mail filters, visit settings.