| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
conf
|
| |\ |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
This does what I can think of so far:
1) Make sure low latency < high latency, low loss < high loss
2) Loss interval must be at least latencyhigh otherwise every packet that was high latency would be counted as lost before it came back. (see note below)
3) averaging time period must be at least 2 times probe interval - it is not much of an "average" if it averages less than 2 probes :)
4) alert interval must be at least probe interval - there is no point recalculating the average latency and loss more often than once every probe interval.
5) Criteria for showing or hiding the advanced options on page load fixed up to account for all the fields now in the advanced section.
6) Additional information - I have written some stuff that I think is now helpful.
Note: Currently the default loss interval is 500 and latencyhigh is also 500. This makes no sense to me. If a probe comes back in > 500ms then the thread that is waiting for the reply will have given up (loss interval has expired). So any packets with an RTT > 500ms will be considered lost. Therefore there will be no packets recorded with an RTT > 500ms. Therefore the average latency can never exceed latencyhigh.
It seems to me that "loss interval" needs to be reasonably higher than "latencyhigh" in any sensible configuration.
Thoughts?
|
| |
|
|
| |
we don't break current database. Ticket #5624
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| | |
White space and text or comment typos only - nothing functional.
|
| | | |
|
| | | |
|
| |/ |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On nanoBSD there is a "Proceed with upgrade?" question warning about the duplicate slice. After answering "y" to that, the system does the duplicate slice, which takes some minutes. Then it asks again "Proceed with upgrade?" after displaying all the packages it will install.
That is a bit annoying at the console - I answer "y" and go off to make a cup of tea, only to come back and find that it is waiting asking again.
On nanoBSD a reboot is known to be required anyway, because even if it is some little package that gets upgraded, and not the core OS, the partition is always switched. So we can say that in the first warning and then skip asking "Proceed with upgrade?" a second time.
What do you think? Should it ask a 2nd time after displaying the packages to be installed? Or is it OK to skip that confirmation prompt?
Also, I moved the call to setup_nanobsd_env inside the "if nanobsd" - it worked like it was because setup_nanobsd_env returns without doing anything if the system is not nanobsd, but it just looked odd and there seems no point calling it when not nanobsd.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
on factory default boot.
This allows the system to switch interfaces from the newer ones in the
default config (e.g. em0 em1) back to the interfaces used by:
Alix - vr1 vr0
APU - re1 re2
that match the WAN and LAN labels printed on many existing devices.
It means these devices can boot the default config and this will
automatically detect that there is no em0/em1 and will instead select
whatever exists out of vr1/vr0 or re1/re2. This avoids the user having
to use the serial cable to do interface assignment when starting a brand
new image, or when resetting to factory defaults. It could easily be
extended to other common interface combinations.
For me, this (or similar) would be very beneficial. At remote sites it
is really good if it is possible to do reset to factory defaults, or put
a fresh CF/SD card in, and the system boots without needing to connect a
serial cable and do interface assignment.
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | | |
Add write_config function option to only write the config. Sometimes syncing firewall is not necessary or desirable. ex: changing log display options.
|
| |\ \ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This file previously had to have a space after "Do you want to proceed [y|n]?" to make the prompt for user input nice. That made it one of the few exceptions to the code style guide, where lines are not supposed to have blank space at the end.
Might as well have 1 less exception to the rule by internationalizing it, which removes the literal "EOD" echo output stuff.
|
| |\ \ \ \ \ |
|
| | |/ / / /
| | | | |
| | | | |
| | | | | |
This file previously had to have a space after "Do you want to proceed [y|n]?" to make the prompt for user input nice. That made it one of the few exceptions to the code style guide, where lines are not supposed to have blank space at the end.
Might as well have 1 less exception to the rule by internationalizing it, which removes the literal "EOD" echo output stuff.
|
| |\ \ \ \ \ |
|
| | |/ / / /
| | | | |
| | | | | |
This is another one that was using echo EOD stuff and needed a space after "Do you want to proceed [y|n]?".
|
| |\ \ \ \ \
| |_|_|_|/
|/| | | | |
|
| | |/ / /
| | | |
| | | |
| | | | |
This code is a whole mix of some palces that use gettext() and other chunks of output that are hardcoded text between "EOD" markers.
I have got rid of the "EOD" blocks where there is a question asked - those needed to have a space at the end of the question. To meet code style guide it is easy if questions are all in their own echo statements and the space " " can be visibly coded in.
|
| |\ \ \ \ |
|
| | |/ / /
| | | |
| | | | |
These debug blocks look like they should not be in production. if 'debug' is turned on, then they would always log_error() and return for all log lines, even good ones.
|
| |\ \ \ \ |
|
| | | | | | |
|
| |\ \ \ \ \ |
|
| | |/ / / /
| | | | |
| | | | |
| | | | | |
The packet loss thresholds must still be in % ? milliseconds does not look valid.
Other things are minor formatting.
|
| |\ \ \ \ \ |
|
| | |/ / / / |
|
| |\ \ \ \ \
| |/ / / /
|/| | | | |
|
| |/ / / / |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
dpinger always pass 3 parameters to alert_cmd, what can make pfSctl confuse,
This script will be called by dpinger when alarm goes on or off, then
it's going to call pfSctl
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \ |
|
| | | | | | |
|
| |/ / / / |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When -p is used on nanobsd, progres socket must be created on secondary
partition (chroot_dir) otherwise pkg, that runs with -c chroot_dir,
will not be able to find UNIX socket to connect and send events
|
