Trouble-shooting and Analysis
Calibration and Mount Control Problems
If
you are just starting to use PHD2 or are connecting to new equipment
for the first time, you may have trouble getting the guider calibration
done. This problem usually takes one of two forms, each requiring
different responses:
- The
star moves during calibration but
it moves "too far" or "too little." If you've used the
new-profile wizard and have provided correct values for focal length,
camera pixel-size, and mount guide speed setting, the "step-size" used
in calibration should
already be correct. But if you've configured your profile by hand
or have changed guide speed settings in the mount, you may need
to adjust the 'calibration step-size' parameter in the 'Guiding'
tab of Advanced Settings.
The help content there describes how this parameter is used, and you
should be able to resolve the problem quickly. But if you've used
the new profile wizard and are seeing problems with "too far" or "too
little" guide star movement, the problem probably lies elsewhere.
- The
star doesn't move enough during RA calibration, declination
backlash clearing, or Dec calibration. These problems
are announced by alert messages at
the top of the display window. With longer focal
lengths, small movements may even be the result of seeing
deflections, and the mount isn't
really moving at all. Dealing with this sort of problem is
described next.
In
nearly all cases, the "no movement" problem is caused by failures in
the hardware or, even more likely, problems in the cabling and
connections. The best tool for trouble-shooting this is the
'Manual Guide' option under the 'Tools' menu, as described in the Tools
section of this help document. Simply use the directional
controls in the 'Manual Guide' window to send commands directly to the
mount while watching a star in the image display window. Use
fairly large guide pulse amounts - at least several seconds - so you
can clearly see if the mount is moving. Try to move the mount
in all four directions and verify the target star is moving by roughly
equal amounts. If the mount does not respond, you know you have
either
hardware or connectivity problems to resolve - nothing to do with PHD2.
If you're using a Shoestring device to connect to the mount,
watch its indicator lights to see if the commands are reaching it.
Similarly, your ST-4 compatible guide camera may have indicator
lights to show when guide commands are being received. If you're
using an ASCOM connection to the mount, be sure the COM port
assignments are correct. You can also use some of the
ASCOM-supplied tools like POTH to be sure the ASCOM driver is
communicating correctly with the mount. It is best to use the
latest version of the ASCOM driver for your mount because older
versions of these drivers often had bugs associated with pulse-guiding.
Calibration Sanity-Checks and Alerts
It
is also possible that the calibration process will complete but PHD2
will post a calibration alert message saying that some of the results
are
questionable. This "sanity check" dialog will show an explanation
of the issue and some details of the calibration results:
Starting with the 2.4.0 release, there are four things checked by PHD2:
- Too
few steps (shown above) - resolving this issue can be easy assuming the
mount is actually working correctly.
Just adjust the calibration step-size downward until you get at
least 8 steps in both the west and north calibrations. If you
used the new profile wizard to set up your configuration, a good
starting value for calibration step-size will already be set. If
you find that the number of steps in RA and Declination is
substantially different, you are probably seeing evidence of
declination backlash unless you are using different guide speed
settings on
the two axes.
- Non-orthogonal
camera axes - the camera axes are normally computed independently even
though they should
be perpendicular. The angle calculations do not require
great precision, but if they are signfiicantly non-orthogonal, you
should repeat the calibration. If you see repetitive alerts of
this type and the axes are significantly non-orthogonal, you'll need to
identify the problem and fix it. Common causes are
bad polar alignment, large declination backlash, or large periodic error in RA. Any of
these problems can cause the guide star to move significantly on one
axis while PHD2 is trying to measure its motion on the other axis. If
you suspect these problems, go ahead and accept the calibration, then
run the Guiding Assistant to measure your polar alignment error, declination backlash,
and RA tracking error. In other cases, the mount
may not be moving at all, and the measured
displacements of the star are just caused by seeing effects.
This sort of problem should be obvious in the calibration graph
at the left of the dialog. If the axis error is relatively small
and you are convinced the
hardware is working properly, you can avoid further alerts of this type
by setting the
option to 'Assume Dec orthogonal to RA' in the 'Guiding' tab of the
Advanced Setup dialog. But you should do this only if the error is
fairly small - otherwise, you are simply ignoring a serious problem.
- Suspicious
RA and Dec rates - assuming the guide speeds in the mount are the same
for both axes, the measured guide rate for right ascension should be
related
to the declination guide rate by approximately a factor
of cosine (Declination). In other words, the RA rate gets
smaller as you move the scope further away from the celestial equator
(Dec=0). PHD2 won't try to identify
which rate is incorrect - it is simply alerting you that something
looks wrong with the rates. You can sanity check these rates
yourself quite simply. If you are guiding at 1X sidereal rate,
your declination guide rate should be approximately 15 arc-sec/sec;
with a guide rate of 0.5X sidereal, the declination rate would be 7.5
arc-sec/sec,
etc. A declination rate that is significantly smaller than the RA
rate is often an indication of substantial declination backlash.
Using a calibration that triggered this alert can lead to
over-shooting in Dec guiding because the actual guide rate is probably
larger than the measured one. To work around this problem, you
should manually clear the Dec backlash before starting calibration.
You can do this in either of two ways: 1) make sure the mount's
last slew direction was north or 2) use the hand controller to manually
move the mount north at guide speed for 20 seconds.
- Inconsistent results - if the calibration results are
significantly different from your last-used calibration, an alert
message will be generated. This may happen because you've made a
change in your configuration. That doesn't imply a real problem,
but you should probably consider creating a separate profile for the
new configuration. By doing so, PHD2 will remember settings
for each of your profiles, letting you switch between them easily.
If you haven't made a configuration change, you will probably
want to determine why the results are so different.
- Too
little east or south movement - The calibration process uses only the
west and north moves to compute the camera angle and rates of movement.
The east and south moves are done primarily to restore the guide
star somewhere close to its starting position. If little or no
east or south movement is seen, you may see an alert message advising
you of the situation. The calibration hasn't failed, but guiding
is likely to be impaired. The most common causes are a defective
guide cable if using ST-4 guiding or very large Declination backlash if
the alert is related to south moves.
With
any
of these alerts, the relevant data field will be highlighted based on
the
type of message. You can choose to ignore the warning ('Accept
calibration'), re-run the calibration ('Discard calibration'), or
restore your last good calibration ('Restore old calibration').
With the third option, you can defer calibration until later and
start guiding with your last good calibration data. If you see
repeated alerts on the same topic and are convinced there really
isn't a problem, you can use the 'don't show' checkbox to block
future alerts of that type. But you should be aware that the
sanity-checking used by PHD2 works well for a wide range of equipment,
and most users don't see these calibration alerts at all.
Declination Backlash
By
far the most common source of calibration problems is declination
backlash, which is present to some degree in most geared mounts.
With many less-expensive mounts, however, the problem can
be severe and
can lead to poor calibration and guiding results. Consider the
following
example of a calibration review dialog:
The
first clue to the problem is found by comparing the number of steps
required for calibration on the two axes - 10 for RA but 42 for Dec.
This shows the mount was not moving consistently in
declination, probably because the backlash had not been
effectively cleared. This also explains the "wandering" behavior
of the declination points (light green) when the guide commands were
reversed from north to south. Finally, the computed declination rate is
much smaller than the RA rate even though the guide speed settings on
the two axes were identical. In fact, this would have triggered a
calibration alert dialog.
There are
actually two problems to be addressed here. First, the
calibration result is poor and should be repeated in order to get a
more accurate measure of the declination guide rate. Second, the
mount is likely to behave badly during direction reversals in
declination even if the dec guide rate is correct. The
calibration can be improved by first manually moving the mount
north at
guide speed for 10-20 seconds until consistent star
movement is seen in the main window. You can do this with
the 'Manual Guide'
tool or by using the hand-controller on your mount. Once this is
done, most of the declination backlash in your mount should have been
overcome. You can then repeat the calibration procedure
and probably get a declination guiding rate that is more
reasonable.
The underlying backlash problem generally requires some mechanical adjustment
to the mount. You can try using a backlash compensation setting,
but this is not likely to work well if the backlash is large -
more than 2-3 seconds, for example. If you can't correct
the
backlash or reduce
it to manageable levels, you should consider choosing uni-directional
guiding for declination. To do this, you determine
which way the mount drifts due to polar alignment error, and tell PHD2
to guide only in the opposite direction (see Uni-directional guiding). This is controlled by the 'Dec
guide mode' control on the'Algorithms' tab of the Advanced Dialog.
For example, if the
mount tends to drift north overall, restrict guide commands to
south-only. This is not an ideal solution, obviously, but you can
still use reasonably long exposures and achieve decent guiding results
- and there are plenty of imagers out there who use this technique
effectively.
If you have an unusual circumstance, such as a mount with no
declination control at all, you can set the 'Dec guide mode' choice to
'Off'.
Validating Basic Mount Control - the Star-Cross Test
If you are having repeated
problems getting calibration to complete without alert messages, you
should run a very simple test to see if the mount is responding to
guide commands. This test basically mimics what is done during
calibration, but it is more direct and can give you a better feel for
what's going on. We'll call it the "star-cross" test. The
idea is to open the shutter on the main imaging camera, then send guide
commands that should cause the stars in the field to trace out a
distinctive cross pattern. In other words, you want to get an
image that looks something like this:
The angular orientation doesn't matter, that's just a function of how you
have the guide camera rotated. What is important is that the
lines in the cross are perpendicular and have roughly equal lengths in
each of the four directions relative to the starting point in the
center. If the image you get doesn't have this approximate
appearance, guiding will either be impaired or perhaps impossible.
For example, consider the following poor result:
You
can see the star has moved along only one axis - only
in right ascension in this example. The declination guide
commands sent to the mount did nothing at all. Until this is
fixed in the mount, you won't be able to guide in declination at all
and will have to disable declination guiding to even complete a
calibration. There are many other permutations of bad
results, each suggesting a particular problem in the mount, the guide
cable, or much less likely, the ASCOM driver for the mount. You
can safely assume it has nothing to do with PHD2.
Here are the steps for running the test:
- Set the mount guide speed to 1X sidereal. Bring up
the 'Manual Guide' tool in PHD2 and choose an initial pulse size - start with,
say, 5 seconds.
- Start a 60 second exposure on the main camera.
- Send
a 5-second pulse west, then two 5-second pulses east, then a final
5-second pulse west. This should return the star to its
approximate starting position. You should wait about 5
seconds after sending each guide pulse to give the command time to
complete before sending the next pulse.
- Now send a 5 second pulse north, then two 5-second pulses south, then a final
5-second pulse north. This should again return the star to its starting position.
-
Wait for the main camera image to download and see what you get.
You
can use different pulse lengths if you want, perhaps using smaller
values to confirm the mount will respond to them. Just be sure
the total exposure time on the main imaging camera is longer than the
total of guide durations plus a margin for error. On most mounts,
the star will not return to its exact center because of some
declination backlash - you can see that in the first example image. But
it should be fairly close or you'll need to look more carefully at how
much declination backlash you have in the mount. PHD2 also has a star-cross test tool, descibed here: Star-cross Tool. You can use that to automatically perform the test steps described in 1-5 above.
One benefit to
using this test is that it reduces things to the absolute basics: will
the mount move as directed or not. It has nothing to do with PHD2
guide settings because they aren't involved in the test. You may
find it helpful to use the test results to communicate with the mount
manufacturer or other users who understand that specific mount and its typical problems.
Measuring the Mount's Behavior
If you're having trouble
getting decent guiding results, your first instinct will probably be to
try making wild changes to the guiding parameters in the hope of
finding a magic solution. This almost never works, and you're
more likely to just make things worse. If the default parameters
from the new-profile-wizard aren't producing reasonable results, the
fault is probably with the hardware and you'll need to determine the
underlying cause. Once you understand the cause, you can probably
improve your guiding results even if no actual repairs can be made -
but understanding the underlying problem is important. To
understand what the mount is doing, perform the following steps:
1. Use the new-profile-wizard to create a new equipment profile for the test, being sure the guide scope focal length and camera pixel size are correct. Don't guess at them, look them up if you aren't sure.
2. Use an ASCOM connection to the mount if one is available.
3.
Perform a fresh calibration near Dec=0 with the scope pointing at least
40 degrees above the horizon to minimize seeing effects.
4. Make
sure there are no backlash compensation settings active in the mount,
and set the mount guide speed to 0.5x - 1x sidereal.
5. Run the
Guiding Assistant for 10-15 minutes and apply whatever recommendations
it makes, particularly with respect to min-move values. Let it
measure your declination backlash. You may need to use a large
tracking region to avoid losing the guide star during this part of the
process - just be sure there aren't multiple stars in the tracking
rectangle. The backlash test will move the star a long distance
north, so choose a guide star that is nearer the southern edge of your
camera frame to give yourself plenty of room.
6. Do not change any of the guide parameters beyond what is recommended by the Guiding Assistant.
7.
Take a careful look at the results shown in the Guiding Assistant
table. Each entry in the table can tell you something useful
about the mount's performance. These results are also written to
the guiding log, so they are available for later analysis.
8.
If you got calibration alert messages in step 3, you should probably
remedy those problems before proceeding. Guiding with a bad
calibration is not likely to produce good results. Also, if your
polar alignment error is 10 arc-min or more, you should improve on that
and then repeat the above steps.
9. Let PHD2 guide for another 10-15
minutes, just letting it run so long as there aren't gross errors from
wind or other "mistakes." Do NOT change any of the guiding parameters while this is being done.
If
you want to analyze the results yourself, use the PHDLogView tool and
the tutorial on Analyzing PHD2 Guiding Results. You should also
consult the document on PHD2 Best Practices. All of these
references are available on the OpenPHDGuiding.org web site under the
'News' tab. If you'd like some help understanding the results,
post both the guiding and debug log files on the OpenPHD2 Google forum
and we'll be glad to help you out.
Display Window Problems
New users often complain
that the image displayed in the main window is extremely noisy or is
almost all-white or all-black. Assuming the camera is
functioning and actually downloading images, the display issues are
often caused by the absence of any usable stars in the frame. For
example, trying to test the camera indoors or in daylight will almost always create
these conditions. The appearance of the image display window in
these situations provides no useful information and should be
discounted. PHD2 uses an automatic screen-stretching function
that is intended to help you see real stars under a nightime sky.
When no stars are present, the display will be stretched to show
the range of minimum-to-maximum brightness values of whatever is in the
frame - which is often nothing at all. This is usually what
causes the noisy/all-white/all-black display results. You may
also encounter display problems if the guider is not well-focused.
Focusing the guider can be a tedious and frustrating experience
but it's critical to getting good guiding results. A good
technique is to start with a bright but unsaturated star and try to reach focus with that. Then move to successively fainter stars to fine-tune the focus position.
Hot-pixel Problems
Even
with some high-quality guide cameras, you may encounter problems where
clumps of hot pixels are mistaken by PHD2 as guide stars.  For many cameras, a
simple dark frame will suffice for reducing or eliminating hot-pixel
problems, and dark frames should always be used as a starting-point.
But for other cameras, you will need to build a bad-pixel map and
update it as necessary when you see changes in the locations and sizes
of defective pixels. Camera sensors change over time and may
react to changing temperatures, so bad-pixel map maintenance is a small
task you should be able to perform. Step-by-step instructions can
be found in the Bad-pixel map
chapter of this document. These problems are different from
transient hot pixels, which can be caused by cosmic ray strikes on the
sensor. Although cosmic ray hits can disrupt guiding, there's
really nothing you can do about them.
Restoring a Working Baseline
Despite advice to the contrary, you may have made rapid, uninformed
changes to your guiding parameters only to find the performance stayed
the same or even got worse. Before proceeding, you should restore the
settings to their default values. If you used the
new-profile-wizard to build your profiles, the parameters will have
been set based on the specifics of your configuration, and they are
likely to be pretty close. If you encounter significant
guiding problems using those settings, you are probably having
issues with the mount or other hardware. Blindly changing guiding
parameters almost never solves these problems and quite often makes
things worse. You have several options for restoring the settings
to their default values:
- On the 'Algorithm' tab of the
Advanced Dialog, you can individually reset parameters by looking at
the tool-tip for each field. Hover your mouse cursor over the
field and the default value will be displayed. Note that this is
not accurate for the min-move settings, which depend on your image
scale. This approach is best when you want to restore only a few
settings.
- Click the 'reset' buttons on the 'Algorithm' tab for
the selected RA and Dec guide algorithms. This is the recommended
approach for resetting all the guiding parameters. The min-move
settings will be reset to the values originally calculated by the
new-profile-wizard. If you subsequently adjusted those settings
by running the Guiding Assistant, you should repeat that process.
- Run the new-profile-wizard, accessed by clicking on the 'Manage Profiles' button in the 'Connection' dialog.
Use the same camera and mount choices you already have and give
the profile a new name. If you want to re-use the dark library
and bad-pixel map from the old profile, connect to the new profile and
use the 'Darks' menu to import those files from the old profile.
Once you are satisfied with the new profile settings, you can
delete the old one.
Camera Timeout and Download Problems
In
some cases, you may experience problems where guider images aren't
downloaded or displayed. In extreme cases, this may even cause
PHD2 or other camera-related applications to be non-responsive (i.e. to
"hang"). Again, this is almost always due to hardware, camera
driver, or connectivity issues, with one of the most common
culprits being a faulty USB cable or device. It is highly
unlikely to be caused by an application like PHD2,
so you should begin
your investigation at the lower levels of the system. You can start by
confirming that the guide camera is working - try using a short, direct
cable from the camera to the computer and taking exposures with
the native or test application that came with the camera.
If the
camera is functional, you can start looking at USB
hubs and cables, swapping them one at a time to see if you can isolate
the problem. It's worth remembering that we work in
a hostile
environment while doing our imaging, and many of the components we use
are not designed for cold, outdoor conditions. So something that worked
just last week or last month may no longer be reliable.
Starting
with the 2.3 release, PHD2 uses a camera timeout property to protect
against hang conditions. This property is set in the Camera tab
of Advanced Settings. and uses a default value of 15 seconds. This means that PHD2 will wait up to 15 seconds after the completion of the exposure
to receive the image from the camera. This is a very generous
amount of time and should work well for the majority of cameras.
However, some cameras are known to create problems by
making large bandwith or power demands on the USB subsystem.
If you are getting timeouts of this sort and are convinced the
camera is working properly, you can increase this timeout value. You can even change it to a very
high number - even 1000 seconds or more - so that timeout errors are never shown. Doing so leaves you
vulnerable to apparent hangs in the user interface and erratic guiding
behavior, but it is a choice you can make for yourself. A larger
value for the timeout will not create extra delays during normal camera
operations - once the image is downloaded from the camera, the timer is cancelled and guiding will proceed immediately.Poor Guiding Performance
Once
you've gotten everything running, you will probably get reasonably good
guiding results almost immediately. You will have to decide what
"good enough" means, and everyone's standard is likely to be different.
But if you find your imaging results are not acceptable
because the stars are streaked or elongated, you'll need to take a
systematic approach to correcting the problems. It is often
tempting to just start blindly adjusting the various guide parameters
in an effort to make things better. There is nothing wrong with
adjusting the parameters - that's why they're there - but it should be
done carefully based on an understanding of what they do. The
PHD2 default settings are carefully chosen to produce reasonable
results for most amateur equipment and locations. Optimal
settings are entirely dependent on the image scale, seeing conditions,
and behavior of your specific mount. In other words, they are
unique to your situation - there is no magic "red book" of correct
guiding parameters, and settings you get from other users may be
completely irrelevant to your situation. If you got started by
using the New-Profile wizard, the default settings will already be
tuned somewhat to match your image scale. By using the Guiding
Assistant, you can get more specifics about your situation - how the
seeing conditions look and how you might adjust the minimum-move
settings to avoid chasing the seeing. You can also use either the
Guiding Assistant or the Manual Guiding tool to see how much backlash
is present in your mount, something that can be important to understanding your declination guiding results.
Achieving the best possible guiding performance can be a
complex task and not something that can be covered here. However, you
can get help on the web from a variety of sources, with the document by
Craig Stark being a very good place to start:
http://www.cloudynights.com/page/articles/cat/fishing-for-photons/what-to-do-when-phd-guiding-isnt-push-here-dummy-r2677.Alert Messages
PHD2
will sometimes display alert messages at the top of the main display
window. These generally show error or diagnostic information that
warrant your attention. During normal operation, you probably
won't see any of these, but if you do, this section can help you decide
what to do about them.
Dark-library and Bad-pixel Map Alerts
"Use a Dark Library or a Bad-pixel Map"
- using a dark library or bad-pixel map reduces the likelihood that
PHD2 will mistakenly identify hot pixels or some other image defect as
a star. If you choose to ignore this message, you'll be
vulnerable to situations where PHD2 inadvertently switches from the
guide star to a hot pixel and no longer guides correctly.
Format/geometry mismatches
- dark frames and bad-pixel maps must match the format of the sensor in
the camera being used. If you've changed the camera in an
existing profile, the existing dark/bpm files will not be usable and
you'll see this alert message. To avoid seeing the message,
you should
instead create a new profile when you change cameras. You'll still need
to shoot new darks or bpms, but you can keep the old files for use with
the original camera. In very unusual
circumstances, you may see this message when either the
driver or PHD2 code for handling the camera has changed. You might
also
see a
format-incompatibility alert message if you have an old dark library
that has somehow accumulated frames with different sensor formats.
In
any of these cases, you should rebuild the dark library or bad-pixel
map from scratch - more information can be found here: Dark Frames and Bad-pixel Maps
ASCOM Alerts
When
you first connect to a mount, camera, or other ASCOM-controlled device,
you may see an alert message saying that a required capability is not
supported by the driver. One example would be lack of support for
pulse-guiding by an ASCOM telescope/mount driver, something that can
occur with outdated drivers. In these situations, your only
recourse is to update the ASCOM driver. These drivers are
generally available from the ASCOM web site or, in some cases, from the
device manufacturer. As
a rule, the best practice is to use the latest versions of these
drivers so you don't encounter problems that have already been
identified and fixed.
You might also see other alert messages associated with the ASCOM driver for the mount:
1.
"PulseGuide command to mount has failed - guiding is likely to be
ineffective." This is usually caused by a bug or timing
sensitivity in the ASCOM mount driver, and there is generally no way to
know if the guide command was executed properly or not. If
you rarely see the alert and your guiding results are acceptable,
you can probably ignore it. Despite the alert condition, PHD2
will continue to issue guide commands, so you don't need to take any
immediate action. If you see the alert frequently, you should
send us your debug log so we can understand the details of the problem
and possibly help you describe it to the author of the ASCOM driver.
2.
"Guiding stopped: the scope started slewing." This is pretty
self-explanatory, but the determination that the scope was slewing is
something reported to PHD2 by the ASCOM mount driver. Whether it
was actually slewing isn't known to PHD2. Assuming you didn't
mistakenly slew the scope with guiding active, there is probably a
timing problem in the driver. If you want to sidestep the problem
temporarily, you can disable the logic to check for slewing - go into
the 'Guiding' tab of the brain dialog, and un-check the box that says
"Stop guiding when mount slews." This will let you continue
guiding, but the results might be suspect. The debug log should
provide the details needed to describe the problem to the author of the
ASCOM driver.
Camera Timeout Alerts
Alert messages associated with camera timing/timeout problems are discussed above: Camera Timeouts
Calibration Alerts
A number of alerts may appear during the mount calibration process. These are described here: Calibration Alerts
Maximum-Duration Limit Alerts
During
normal guiding, you may see an alert message saying that your settings
for maximum-duration limits in RA or Dec are preventing
PHD2 from keeping the guide star locked. If you've decreased
these parameters from their default values, you should consider
increasing them. However, if the limits are well above one second,
this alert probably indicates you've encountered a mechanical problem
that needs to be corrected. In the simplest cases, you may have
suffered a cable snag, wind gust, mount bump, or other external event
that caused the guide star to move by a large amount. In such
cases, you simply need to correct the problem if you can and proceed
with guiding. But in other cases, the alert may be triggered by a
steadily growing guide star displacement that is not being corrected at all.
For example, if PHD2 can't move the mount correctly in either the
north or south directions, the cumulative uncorrected error will
eventually reach a point that triggers the alert. These sorts of
problems will require careful diagnosis and correction and simply
increasing the maximum-duration limits will not help.
Log Analysis
Any
sort of problem isolation or tuning will invariably require use of
the PHD2 log files. Both are formatted for straightforward
interpretation by a human reader, and the guide log is constructed to
enable easy import into other applications. As mentioned in the
'Tools' section, applications such as PHDLogViewer or Excel
can
be used to visualize overall performance, compute performance
statistics, and examine time periods when guiding was problematic.
With Excel or similar applications, simply specify that the guide
log uses a comma as a column separator.
Guiding Log Contents
The
contents of the guiding log will continue to evolve as new capabilities
are added. But the basic content is stable, and considerable care
is taken to not "break" applications that parse it. If you wish
to analyze the log yourself, the following information will be helpful.
The PHD2 guide log will contain zero or more sequences of
calibration and zero or more sequences of guiding. Each of these sections has a
header that provides most of the information about the guiding algorithms being
used and the internal parameters used by PHD2 for guiding. At the start of either a calibration run or
a guiding sequence, the last line of the header information defines a set of
column headings. The meanings of those
columns are shown below:
Calibration columns:
- dx, dy
are offsets from the starting position, in pixels, in the camera coordinate
system
- x, y are the camera x/y coordinates of the guide
star at the end of each calibration step
- Dist is the total distance moved in the camera
coordinate system (dist = sqrt(dx*dx + dy*dy).
This is the value used by PHD2 to compute the calibration parameters
Guiding columns:
- dx, dy are the same as for calibration - offsets
from the "lock position" of the guide star in the camera coordinate
system
- RARawDistance and DECRawDistance - these are the
transforms of dx and dy into the mount coordinates - in other words, they use
the arbitrary angle of the guide camera to map from X/Y on the camera to RA/Dec
on the mount
- RAGuideDistance and DECGuideDistance - these are
the outputs from the various guiding algorithms. The guide algorithms operate on the
"raw" distances and decide how far, if any, the telescope position
should be adjusted in each axis. For
example, with a "minimum move" parameter set, the "guide"
distances can be zero even when the "raw" distances are non-zero.
- RADuration, RADirection, DECDuration, DECDirection
- these are the values determined by the two "guide" distances
above. The "durations" are the
lengths of the guide pulses, in milliseconds, needed to move the mount by the
distances specified by RAGuideDistance and DECGuideDistance
- XStep, YStep - step-adjustment durations for the
adaptive optics device if one is being used
- StarMass - a brightness measure of the guide
star image
- SNR
- an internal "star-detection ratio" used by PHD2 - essentially a
measure of how well the star can be distinguished from the sky
background
- ErrorCode - an integer value representing the quality of the guide star measurement:
- 0 - no error
- 1 - star is saturated
- 2 - star has low SNR
- 3 - star mass is too low for accurate measurement
- 4 - star has drifted too near the edge of the frame
- 5 - star mass has changed beyond the specified amount
- 6 - unexpected error
All distance values are in units of pixels. The header for the guiding section will show
the image scale as it is known by PHD2, and that can be used to scale the pixel
distance values into units of arc-seconds if desired.
Problem Reporting
If
you encounter application problems that are specific to PHD2, you
are encouraged to report them to the open-phd-guiding Google group: https://groups.google.com/forum/?fromgroups=#!forum/open-phd-guiding.
Obviously, the more information you can provide, the more likely
we will be able to resolve the problem. Using the following
guidelines will help in that regard:
- Try to reproduce the
problem - if we have a clear set of steps to follow, we are more likely
to find a solution quickly. If you can reproduce it, try to
reduce things to the minimum number of steps. Remember, we won't
have your hardware or computer environment when we try to reproduce it
ourselves.
- Try to be complete about describing your configuration - operating system, equipment types, PHD2 version, etc.
- Attach
the PHD2
debug log from the session in which you encountered the
problem. You can find the debug log in the PHD2 folder in your
Documents folder. If you can't reproduce the problem, try to
estimate the
time of day when you first saw it - this could help us find evidence in
the debug log without having to sift through hundreds of lines of
output. The 'Upload log files' function on the 'Help' menu can help you find and upload the log files.


Samarth uses technology to organise Skill & Job marketplace by covering large amount of population to its skill database and Job database. Samarth does what UBER did to Taxi based transportation, for the skilled people recruitment across all possible industry and service segments in India as a first goal This is done by organising Skilled people finding for a job of any industry and/or service segment as a well organised, predictable, trustable and reliable online marketplace Hence Samarth can be viewed as a large database of skilled people, jobs currently available, past placement history and outcomes from the placement history, with intelligence to identify next successful placement for either job provider or skilled people
Design difficulties of the App components
Using Component architecture
Implementing new technologies


All locations
About
Methodology
People for bikes
City/Town Search
Filter by city or town name
Sort by
Alphabetical
Highest Rated
Lowest Rated
Last Updated
Compare
3 Selected
Los Angeles, California
90
Remove
Los Angeles, California
90
Remove
Compare Neighborhoods
A
Phoenix, Arizona
Last updated:
August 12, 2017
90
Compare
C
Los Angeles, California
Last updated:
August 12, 2017
90
Compare
Los Angeles, California
Last updated:
August 12, 2017
90
Compare
Los Angeles, California
Last updated:
August 12, 2017
90
Compare
Los Angeles, California
Last updated:
August 12, 2017
90
Compare
Los Angeles, California
Last updated:
August 12, 2017
90
Compare
Los Angeles, California
Last updated:
August 12, 2017
90
Compare
Los Angeles, California
Last updated:
August 12, 2017
90
Compare
Los Angeles, California
Last updated:
August 12, 2017
90
Compare
Previous
Next


The Young and the Restless
Tuesday, April 14 at 12:30 PM
· WCAXDT
NEW
TV14
HD
Phyllis and Jack's wedding day commences; Billy talks to Ashley about the hack at Jabot.
This program could not be recorded. Simple.TV was unable to tune to the selected channel.
The Young and the Restless
Wednesday, May 13 at 12:30 PM
· WCAXDT
NEW
TV14
HD
Victor makes waves at Newman-Jabot; Adam defends Chelsea.
This program could not be recorded. Simple.TV was unable to tune to the selected channel.
No Recordings
Episodes you record will appear here as soon as they're available for watching.


People
Please add @ustc.edu.cn after the alias for faculty and @mail.ustc.edu.cn for students to get the email address.
Faculty
|
Name |
Alias |
Research Interest |
| Professor | Houqiang Li | lihq | Image/Video Coding, Computer Vision |
| Associate Professor | Wengang Zhou | zhwg | Image Retrieval, Computer Vision |
Student
|
Name |
Alias |
Research Interest |
| Ph.D candidate | Jie Huang | hagjie | Sign Language Recognition |
| Ph.D candidate | Yingwei Pan | panywei | Image/Video Caption |
| Ph.D candidate | Min Wang | wm123 | Image Retrieval, Hashing |
| Ph.D candidate | Jianmin Bao | jmbao | Person ReID |
| Ph.D candidate | Yiding Liu | liuyd123 | None |
| Ph.D candidate | Junfu Pu | pjh | Sign Language Recognition |
| Ph.D candidate | Ning Yan | nyan | Video Coding |
| Master student | Yunfeng Wang | wangyf11 | Action Recognition |
| Master student | Yue Lv | lvyue | Image Retrieval |
| Master student | Zhihua Huang | hzh8311 | Face Alignment |
| Master student | Jianglei Huang | hjl777 | Tracking |
| Master student | Ning Wang | wn6149 | Tracking |
| Master student | Zhengguang Zhou | zhgzh164 | Image Retrieval |
| Master student | Jiajun Deng | dengjj | Object Detection |
| Master student | Feng Lin | lin1993 | Face Recognition |
| Master student | Zhihao Zhang | zzh3 | Reinforcement Learning |
| Master student | Yifan Zhang | zyf1 | SAR-Image Processing |
| Master student | Yiheng Liu | lyh156 | Action Recognition |
| Master student | Qiaokang Xie | xieqiaok | Tracking |
| Master student | Yuanqiang Fang | fx520 | Image Retrieval |
| Master student | Qianqian Wang | wqian | Reinforcement Learning |
Alumni
|
Name |
Alias |
Period |
Affiliation |
| Ph.D candidate | Shaoyan Sun | sunshy | Sep. 2012 - Jun. 2017 | Horizon Robotics |
| Ph.D candidate | Zheng Liu | liuzheng | Sep. 2011 - Jun. 2016 | |
| Master student | Tao Liu | liutao1 | Sep. 2014 - Jun. 2017 | iFLY Tek |
| Master student | Xuya Wang | viewer1 | Sep. 2014 - Jun. 2017 | Tencent |
| Master student | Xinchun Qian | qxc | Sep. 2014 - Jun. 2017 | HIK Vision |
| Master student | Jie Sun | sunjieee | Sep. 2014 - Jun. 2017 | HIK Vision |
| Master student | Tianqi Zheng | zhengtq | Sep. 2014 - Jun. 2017 | ArcSoft |
| Master student | Peng Zhang | pzhangoo | Sep. 2013 - Jun. 2016 | Alibaba |
| Master student | Jihai Zhang | jihzhang | Sep. 2013 - Jun. 2016 | Alibaba |
| Master student | Xingyang Cai | xycai | Sep. 2012 - Jun. 2015 | Google |


Team India Pacers Sensational Show At India’s First-ever Pink-Ball Test
by Sridhar RaaviTeam India has cruised to a Sensational Victory in India’s first-ever pink-ball Test at Eden Gardens, Kolkata. Team India trounced Bangladesh with sensational innings and 46 Runs. The major highlight of this test match is that the Pacers have taken all the wickets that have fallen (One Retired Hurt).
Earlier, only once, Team India pacers have taken all the 20 wickets. That is Joburg, South Africa way back in 2017-18. Joburg is a Pace-friendly pitch and this feat has occurred on an Indian Pitch is known to be spinners-friendly. The feat also indicates the renaissance of India’s Pace Factory.
Like never before, India’s Pace Bowling Unit is sensational and is treated as the Best in the Country. This is a significant achievement because pace bowling is one area where Team India always lagged. Ishant Sharma bagged the Man of the Match Award taking Nine Wickets including a five-wicket haul in the first innings.
Umesh Yadav registered another five-wicket haul in the second innings. Interestingly, India Spinners bowled just Seven Overs in the match even as Bangladesh batted for 71.4 Overs in both the innings combined.


1. Introduction
1.1. Value Definitions
This specification follows the CSS property definition conventions from [CSS2] using the value definition syntax from [CSS-VALUES-3]. Value types not defined in this specification are defined in CSS Values & Units [CSS-VALUES-3]. Combination with other CSS modules may expand the definitions of these value types.
In addition to the property-specific values listed in their definitions, all properties defined in this specification also accept the CSS-wide keywords keywords as their property value. For readability they have not been repeated explicitly.
2. Preferred Color Schemes
Operating systems and user agents often give users the ability to choose their preferred color schemes for user interface elements. These are typically reflected in the user agent’s rendering of its navigation interface as well as in-page interface elements such as form controls and scrollbars, and are expected to also be reflected in the values of the CSS system colors.
A UA can also allow the user to indicate a preference for the color scheme of the pages they view, requesting that the author adapt the page to those color preferences. (It is not required to express a preference; users can have preferences for operating system interface colors that they do not want imposed on pages.)
The most common preferences are a choice of “Light” vs “Dark” (or “Day Mode” vs “Night Mode”) color schemes, rendering things as mostly light- or dark-colored backgrounds, and with dark- or light-colored foregrounds (text, icons). This module, together with Media Queries Level 5, defines controls to enable color scheme negotiation for “Light” and “Dark” color schemes (and no preference).
Note: The “Light” and “Dark” color schemes don’t represent an exact color palette (such as black-and-white), but a range of possible palettes. To guarantee specific colors, authors must specify those colors themselves. Note also that, consequently, pairing default or <system-color> colors with author-specified colors cannot guarantee any particular contrast level; it might be necessary to set both foreground and background colors together to ensure legibility [WCAG21].
To enable pages to adapt to the user’s preferred color scheme, user agents will match the prefers-color-scheme media query to the user’s preferred color schemes. See [MEDIAQUERIES-5].
Additionally, if the author has indicated that the page can support this color scheme (see color-scheme), the user agent must match the following to the user’s preferred color scheme:
-
the color of the canvas surface find what we name this in other specs, the initial value of the color property, and the system colors
-
the default colors of scrollbars and other interaction UI
-
the default colors of form controls and other "specially-rendered" elements
-
the default colors of other browser-provided UI, such as "spellcheck" underlines
User agents may support additional color schemes, however CSS does not support negotiation of additional color schemes: user agents should pursue standardization of these schemes, so that prefers-color-scheme and color-scheme can reflect the additional values.
Note: Aside from the small list of adjustments given above, user agents generally do not further adjust a page to match the user’s preferred color scheme, because the chance of accidentally ruining a page is too high. However, when particular color choices are required by the user (for accessibility reasons, for example), more invasive changes might be applied; see § 3 Forced Color Schemes: the forced-color-adjust property.
2.1. Opting Into a Preferred Color Scheme: the color-scheme property
| Name: | color-scheme |
|---|---|
| Value: | normal | [ light | dark | <custom-ident> ]+ | only && light |
| Initial: | normal |
| Applies to: | all elements |
| Inherited: | yes |
| Percentages: | n/a |
| Computed value: | the keyword normal, or optional only keyword and ordered list of specified color scheme keywords |
| Canonical order: | per grammar |
| Animation type: | discrete |
The color-scheme property allows an element to indicate which color schemes it is comfortable being rendered with. These values are negotiated with the users preferences, resulting in a chosen color scheme that affects UI things such as the default colors of form controls and scrollbars as well as the used values of the CSS system colors. Values are defined as follows:
- normal
-
Indicates that the element isn’t aware of color schemes at all, and so the element should be rendered with the browser’s default color scheme.
- [ light | dark | <custom-ident> ]+
-
Indicates that the element is aware of and can handle the listed color schemes, and expresses an ordered preference between them. (See § 2.2 Finding the Used Color Scheme for details on how this choice is resolved.)
Note: Providing both keywords indicates that the first scheme is preferred, but the second is also acceptable if the user prefers it instead.
light represents a “Light” color scheme, with light background colors and dark foreground colors. dark represents the opposite, with dark background colors and light foreground colors.
<custom-ident> values are meaningless, and exist only for future compatibility, so that future added color schemes do not invalidate the color-scheme declaration in legacy user agents. User agents must not interpret any <custom-ident> values as having a meaning; any additional recognized color schemes must be explicitly added to this property’s grammar. To avoid confusion, authoring tutorials and references should omit <custom-ident> from their materials.
only, normal, light, and dark are not valid <custom-ident>s in this property.
Repeating a keyword, such as color-scheme: light light, is valid but has no additional effect beyond what the first instance of the keyword provides.
- only
-
If provided, only indicates that the element must be rendered with one of the specified color schemes, if possible, even if the user’s preference is for a different color scheme.
Per spec, only can only be used with light. Apple’s implementation allows it with dark as well. The concern with only dark is that pages won’t consider UAs that can’t support dark schemes, and will thus render brokenly. This value might be expanded to all schemes or removed entirely depending on further consideration.
Authors should not use this value, and should instead ensure that their page renders well with whatever color scheme the user prefers (using the prefers-color-scheme media query to adjust styles accordingly). This keyword is provided only for the rare cases where that might not be reasonably possible, and using a different color scheme would render the element difficult or impossible to use.
Note: User agents are not required to support any particular color scheme, so using only to indicate a required color scheme is still not guaranteed to have any effect on the rendering of the element.
Note: “Light” and “Dark” modes are not specific color palettes. For example, both a stark black-on-white scheme and a sepia dark-on-tan scheme would both be considered “Light” color schemes. To ensure particular foreground or background colors, they need to be specified explicitly.
2.2. Finding the Used Color Scheme
-
Let scheme be the keyword matching prefers-color-scheme.
-
If the computed value of color-scheme on el contains scheme, return scheme.
-
If the computed value of color-scheme on el contains the only keyword or scheme is no-preference, and at least one color scheme indicated in color-scheme is supported by the user agent, return the first keyword, in specified order, that is supported by the user agent.
-
Otherwise, return no-preference.
For each element, find the used color scheme for that element. If the used color scheme is no-preference, the element must be rendered with the user agent’s default color scheme. (For Web compatibility, this should be a “Light” color scheme.) Otherwise, the element must be rendered with the used color scheme.
Note: This algorithm ensures that if the user prefers a non-default color scheme, it will only be used if the page claims to support it. This ensures that legacy pages, written before color scheme preferences were exposed, do not change behavior.
2.3. Effects of the Used Color Scheme
For all elements,
rendering with a color scheme should cause the colors used in all browser-provided UI for the element—
On the root element, rendering with a color scheme additionally must affect the surface color of the canvas, the initial value of the color property, and the used values of the system colors, and should also affect the viewport’s scrollbars.
In order to preserve expected color contrasts,
in the case of embedded documents typically rendered over a transparent canvas (such as provided via an HTML iframe
element),
if the used color-scheme of the element
and the used color-scheme of the embedded document’s root element
do not match,
then the UA must use an opaque canvas of the Canvas color
appropriate to the embedded document’s color-scheme instead of a transparent canvas.
This rule does not apply to documents embedded
via elements intended for graphics
(such as img
elements embedding an SVG document).
2.4. The "color-scheme" meta
value
To aid user agents in rendering the page background with the desired color scheme immediately
(rather than waiting for all CSS in the page to load),
a color-scheme value can also be provided in a meta
element.
If any meta
elements are inserted into a document or removed from a document,
or existing meta
elements have their name
or content
attributes changed,
user agents must run the following algorithm:
-
Let candidate elements be the list of all
meta
elements that meet the following criteria, in tree order:-
the element is in a document tree
-
the element has a
name
attribute, whose value is an ASCII case-insensitive match forcolor-scheme
-
the element has a
content
attribute, whose value is not the empty string -
the element is a child of the the head element of the document
-
-
For each element in candidate elements:
-
If element’s
content
attribute’s value parses as a <color-scheme> value, treat that value as a declaration of the color-scheme property on element’s root, cascaded as a non-CSS presentational hint. Then return.
-
Note: Because these rules check successive elements until they find a match,
an author can provide multiple such values
to handle fallback for legacy user agents.
Opposite how CSS fallback works for properties,
the multiple meta
elements must be arranged
with the legacy values after the newer values.
This algorithm favors the first meta
,
to allow for ASAP rendering with a chosen color scheme.
Is that the desired behavior?
3. Forced Color Schemes: the forced-color-adjust property
Forced colors mode is an accessibility feature intended to increase the readability of text through color contrast. Individuals with limited vision often find it more comfortable to read content when there is a a particular type of contrast between foreground and background colors.
Operating systems can provide built-in color themes, such as Windows’ high contrast black-on-white and high-contrast white-on-black themes. Users can also customize their own themes, for example to provide low contrast or hue contrast.
In forced colors mode, the user agent enforces the user’s preferred color palette on the page, overriding the author’s chosen colors for specific properties, see § 3.1 Properties Affected by Forced Colors Mode. It may also enforce a “backplate” underneath text (similar to the way backgrounds are painted on the ::selection pseudo-element) to ensure adequate contrast for readability.
To enable pages to adapt to forced colors mode user agents will match the forced-colors media query and must provide the required color palette through the CSS system colors (see [CSS-COLOR-4]). Additionally, if the UA determines, based on Lab lightness, that the Canvas color is clearly either dark (L < 33%) or light (L > 67%), then it must match the appropriate value of the prefers-color-scheme media query and express a corresponding user preference for color-scheme. This will allow pages that support light/dark color schemes to automatically adjust to more closely match the forced color scheme. Behavior between the above dark vs. light thresholds is UA-defined, and may result in assuming either light, dark, or no-preference as the user’s preferred color scheme.
3.1. Properties Affected by Forced Colors Mode
When forced colors mode is active and forced-color-adjust is auto (see below), colors must be force-adjusted to the user’s preferred color palette.
The following user origin declarations [CSS-CASCADE-4] are applied to the element:
color: revert !important; fill: revert !important; stroke: revert !important; text-decoration-color: revert !important; text-emphasis-color: revert !important; border-color: revert !important; outline-color: revert !important; column-rule-color: revert !important; scrollbar-color: revert !important; -webkit-tap-highlight-color: revert !important; /* ISSUE: This is not in a spec anywhere! */ box-shadow: none !important; text-shadow: none !important;
For elements that have a background specified in the UA style sheet, the background color is forced via:
background-color: revert !important;
Whereas for all other elements, the background-color is instead adjusted by forcing all channels other than alpha to match Canvas.
Additionally, on on user input controls (except button-like controls) only:
background-image: none !important;
UA may further tweak these forced colors mode heuristics to provide better user experience.
Note: See [CSS-CASCADE-4] for information about cascade origins and the revert keyword.
3.2. Opting Out of a Forced Color Scheme: the forced-color-adjust property
| Name: | forced-color-adjust |
|---|---|
| Value: | auto | none |
| Initial: | auto |
| Applies to: | all elements |
| Inherited: | yes |
| Percentages: | n/a |
| Computed value: | as specified |
| Canonical order: | per grammar |
| Animation type: | discrete |
The forced-color-adjust property allows authors to opt particular elements out of forced colors mode, restoring full control over the colors to CSS. Values have the following meanings:
- auto
-
The element’s colors are automatically adjusted by the UA in forced colors mode.
- none
-
The element’s colors are not automatically adjusted by the UA in forced colors mode.
Authors should only use this value when they are themselves adjusting the colors to support the user’s color and contrast needs and need to make changes to the UA’s default adjustments to provide a more appropriate user experience for those elements.
Should this property be merged with color-adjust somehow?
In order to not break SVG content, UAs are expected to add the following rules to their UA style sheet:
@namespace "http://www.w3.org/2000/svg"; svg|svg { forced-color-adjust: none; } svg|foreignObject { forced-color-adjust: auto; }
4. Performance-based Color Schemes: the color-adjust property
On most monitors, the color choices that authors make have no significant difference in terms of how the device performs; displaying a document with a white background or a black background is approximately equally easy.
However, some devices have limitations and other qualities that make this assumption untrue. For example, printers tend to print on white paper; a document with a white background thus has to spend no ink on drawing that background, while a document with a black background will have to expend a large amount of ink filling in the background color. This tends to look fairly bad, and sometimes has deleterious physical effects on the paper, not to mention the vastly increased printing cost from expending the extra ink. Even fairly small differences, such as coloring text black versus dark gray, can be quite different when printing, as it switches from using a single black ink to a mixture of cyan, magenta, and yellow ink, resulting in higher ink usage and lower resolution.
As a result, in some circumstances user agents will alter the styles an author specifies in some particular context, adjusting them to be more appropriate for the output device and to accommodate what they assume the user would prefer. However, in some cases the document may be using colors in important, well-thought-out ways that the user would appreciate, and so the document would like some way to hint to the user agent that it might want to respect the page’s color choices. The color-adjust property controls this.
| Name: | color-adjust |
|---|---|
| Value: | economy | exact |
| Initial: | economy |
| Applies to: | all elements |
| Inherited: | yes |
| Percentages: | N/A |
| Computed value: | specified keyword |
| Canonical order: | per grammar |
| Animation type: | discrete |
The color-adjust property provides a hint to the user-agent about how it should treat color and style choices that might be expensive or generally unwise on a given device, such as using light text on a dark background in a printed document. If user agents allow users to control this aspect of the document’s display, the user preference must be respected more strongly than the hint provided by color-adjust. It has the following values:
- economy
-
The user agent should make adjustments to the page’s styling
as it deems necessary and prudent for the output device.
For example, if the document is being printed, a user agent might ignore any backgrounds and adjust text color to be sufficiently dark, to minimize ink usage.
- exact
-
This value indicates that the page is using color and styling on the specified element
in a way which is important and significant,
and which should not be tweaked or changed except at the user’s request.
For example, a mapping website offering printed directions might "zebra-stripe" the steps in the directions, alternating between white and light gray backgrounds. Losing this zebra-striping and having a pure-white background would make the directions harder to read with a quick glance when distracted in a car.
5. Privacy and Security Considerations
Applying user color preferences via color schemes or forced colors mode expose the user’s color preferences to the page, which can increase fingerprinting surface.
Additionally, it may be possible for an embedded document
to use timing attacks to determine whether its own color-scheme matches that of its embedding iframe
or not.
6. Acknowledgements
This specification would not be possible without the development efforts of various color adjustment features at Apple, Google, and Microsoft as well as discussions about print adjustments on www-style. In particular, the CSS Working Group would like to thank: Alison Maher, François Remy, イアンフェッティ


When a client detects a new replication group master, the client must synchronize with the new master before the client can process new database changes. Synchronizing is a heavyweight operation which can place a burden on both the client and the master. There are several controls an application can use to reduce the synchronization burden.
When a replication group has a new master, either as specified by the application or as a result of winning an election, all clients in the replication group must synchronize with the new master. This can strain the resources of the new master since a large number of clients may be attempting to communicate with and transfer records from the master. Client applications wanting to delay client synchronization should call the DB_ENV->rep_set_config() method with the DB_REP_CONF_DELAYCLIENT flag. The application will be notified of the establishment of the new master as usual, but the client will not proceed to synchronize with the new master.
Applications learn of a new master via the DB_EVENT_REP_NEWMASTER event.
Client applications choosing to delay synchronization in this manner are responsible for synchronizing the client environment at some future time using the DB_ENV->rep_sync() method.
Instead of synchronizing with the new master, it is sometimes possible for a client to synchronize with another client. Berkeley DB initiates synchronization at the client by sending a request message via the transport call-back function of the communication infrastructure. The message is destined for the master site, but is also marked with a DB_REP_ANYWHERE flag. The application may choose to send such a request to another client, or to ignore the flag, sending it to its indicated destination.
Furthermore, when the other client receives such a request it may be unable to satisfy it. In this case it will reply to the requesting client, telling it that it is unable to provide the requested information. The requesting client will then re-issue the request. Additionally, if the original request never reaches the other client, the requesting client will again re-issue the request. In either of these cases the message will be marked with the DB_REP_REREQUEST flag. The application may continue trying to find another client to service the request, or it may give up and simply send it to the master (that is, the environment ID explicitly specified to the transport function).
Replication Manager allows an application to designate
one or more remote sites (called its "peers") to receive
client-to-client requests. You do this by setting the
DB_REPMGR_PEER
parameter using the
DB_SITE->set_config() method. Replication Manager always
tries to send requests marked with the DB_REP_ANYWHERE
flag to a peer, if available. However, a
DB_REP_REREQUEST message is always handled by requesting
the information from the master. A view can serve as a
peer, but a partial view is more likely to be missing
requested information, which will then be requested from
the master.
Base API applications have complete freedom in choosing where to send these DB_REP_ANYWHERE requests, and in deciding how to handle DB_REP_REREQUEST.
The delayed synchronization and client-to-client synchronization features allow applications to do load balancing within replication groups. For example, consider a replication group with 5 sites, A, B, C, D and E. Site E just crashed, and site A was elected master. Sites C and D have been configured for delayed synchronization. When site B is notified that site A is a new master, it immediately synchronizes. When B finishes synchronizing with the master, the application calls the DB_ENV->rep_sync() method on sites C and D to cause them to synchronize as well. Sites C and D (and E, when it has finished rebooting) can send their requests to site B, and B then bears the brunt of the work and network traffic for synchronization, making master site A available to handle the normal application load and any write requests paused by the election.
Clients in the process of synchronizing with the master block access to Berkeley DB operations during some parts of that process. By default, most Berkeley DB methods will block until client synchronization is complete, and then the method call proceeds.
Client applications which cannot wait and would prefer an immediate error return instead of blocking, should call the DB_ENV->rep_set_config() method with the DB_REP_CONF_NOWAIT flag. This configuration causes DB method calls to immediately return a DB_REP_LOCKOUT error instead of blocking, if the client is currently synchronizing with the master.
Clients attempting to synchronize with the master may discover that synchronization is not possible because the client no longer has any overlapping information with the master site. By default, the master and client automatically detect this state and perform an internal initialization of the client. Because internal initialization requires transfer of entire databases to the client, it can take a relatively long period of time and may require database handles to be reopened in the client applications.
Client applications which cannot wait or would prefer to do a hot backup instead of performing internal initialization, should call the DB_ENV->rep_set_config() method to turn off the DB_REP_CONF_AUTOINIT flag. Turning off this configuration flag causes Berkeley DB to return DB_REP_JOIN_FAILURE to the application instead of performing internal initialization.


You've heard of Batman, Superman, the The Joker and Catwoman. Ever heard of Condiment Man? How about Ambush Bug, or The Question? Yes, they are real fictional characters in the DC Universe and I am here to introduce you to a bunch more DC Superheroes and Supervillians that you probably have never heard of. As a reminder, these superheroes are real and have indeed appeared in the comics. No, I did not know any of this by heart. I am just as amazed as you are.
Curious about oddball superheroes? Click Here to check out the list!
Feeling like an evil streak is about to take over, and want to learn more about the supervillains instead? Click Here!


AbiWord is a word processor which is useful for writing reports, letters and other formatted documents.
This package is known to build and work properly using an LFS-9.1 platform.
Download (HTTP): http://www.abisource.com/downloads/abiword/3.0.4/source/abiword-3.0.4.tar.gz
Download MD5 sum: 04e31887049a8c72297881bc153b77c4
Download size: 11 MB
Estimated disk space required: 605 MB, with docs (76 MB installed)
Estimated build time: 2.4 SBU (Using parallelism=4, with docs)
AbiWord Docs: http://www.abisource.com/downloads/abiword/3.0.2/source/abiword-docs-3.0.2.tar.gz
AbiWord Docs MD5 sum: c92c0e1e2081db20757231a53d80c338
AbiWord Docs size: 1.5 MB
Boost-1.72.0, FriBidi-1.0.9, GOffice-0.10.46, and wv-1.2.9
dbus-glib-0.110, evolution-data-server-3.36.1, gobject-introspection-1.64.0, libchamplain-0.12.20, libgcrypt-1.8.5, libical-3.0.8, libsoup-2.70.0, Redland-1.0.17, telepathy-glib-0.24.1, Valgrind-3.15.0. Aiksaurus, GtkMathView, libwmf, libwpd, libwpg, libwps, Link Grammar Parser, Loudmouth, OTS, and Psiconv
To enable many of the optional dependencies, review the information from ./configure --help for the necessary switches you must pass to the configure script.
User Notes: http://wiki.linuxfromscratch.org/blfs/wiki/abiword
Install AbiWord by running the following commands:
sed -e "s/free_suggestions/free_string_list/" \ -e "s/_to_personal//" \ -e "s/in_session/added/" \ -i src/af/xap/xp/enchant_checker.cpp && ./configure --prefix=/usr && make
This program does not come with a functional test suite.
Now, as the root
user:
make install
In order to install the local help files, a graphics session is recommended.
If you wish to install the local help files, untar and build them first:
The current version of the docs expands to abiword-docs-3.0.1 and not the expected abiword-docs-3.0.2.
tar -xf ../abiword-docs-3.0.2.tar.gz && cd abiword-docs-3.0.1 && ./configure --prefix=/usr && make
and then, as the root
user:
make install
sed ...: This command corrects the source for changes in the dependency enchant-2.2.8.
--enable-plugins="collab openxml goffice
grammar"
: Build some or all plugins. The openxml plugin
enables Abiword to open some .docx
files. The grammar plugin requires Link Grammar
Parser
Choose the right template for your language and locale from the list produced by the following command:
ls /usr/share/abiword-3.0/templates
Create the folder ~/.AbiSuite/templates
then copy the
normal.awt
you want into it:
install -v -m750 -d ~/.AbiSuite/templates &&
install -v -m640 /usr/share/abiword-3.0/templates/normal.awt-<lang>
\
~/.AbiSuite/templates/normal.awt
Change <lang>
by
the above command to fit the name of the file you want.
If you are using multiple languages, you may need to edit the template to use a font with greater coverage (e.g. one of the Dejavu fonts, because Abiword does not use fontconfig and can only display glyphs that are provided in the chosen font.
If you have desktop-file-utils-0.24 installed, you should run the update-desktop-database command to update the mimeinfo cache and allow the Help system to work.
If you have xdg-utils-1.1.3 installed, you should run the xdg-icon-resource forceupdate --theme hicolor command, for the installed icon to be displayed in the menu item.
Last updated on 2020-03-22 05:35:10 -0500


Time update: 1995
2012
Filter by:
Americas
Africa
Asia
Europe
Oceania
Aggregation:
None
by Continent


Reports steps in Cucumber (or some other Gherkin) .feature files that do not have matching step definitions.
Use the quick-fix to automatically create a new step definition.


{{ metadata.get('title') }}
Intro
Performance is a visceral part of the user experience. For many websites, an improvement to the user experience by speeding up the page load time aligns with an improvement to conversion rates. Conversely, when performance is poor, users don't convert as often and have even been observed rage clicking on the page in frustration.
There are many ways to quantify web performance. The most important
thing is to measure what actually matters to users. Events like
onload
or DOM content loaded
may not
necessarily reflect what users experience visually. For example, an
email client might have a very fast onload event but the only thing
loaded is the interstitial progress bar, meanwhile the inbox contents
are loading asynchronously. The loading metric that matters for this web
app is the "time to inbox", and focusing on the
onload
event may be misleading. For that reason this
chapter will look at more modern and universally applicable paint, load,
and interactivity metrics to try to capture how users are actually
experiencing the page.
There are two kinds of performance data: lab and field. You may have heard these referred to as synthetic and real-user measurement (or RUM). Measuring performance in the lab ensures that each website is tested under common conditions like browser, connection speed, physical location, cache state, etc. This guarantee of consistency makes each website comparable with one another. On the other hand, measuring performance in the field represents how users actually experience the web in all of the infinite combinations of conditions that we could never capture in the lab. For the purposes of this chapter and understanding real-world user experiences, we'll look at field data.
The state of performance
Almost all of the other chapters in the Web Almanac are based on data from the HTTP Archive. In order to capture how real users experience the web, we need a different dataset. In this section we're using the Chrome UX Report (CrUX), a public dataset from Google that consists of all the same websites as the HTTP Archive and aggregates how Chrome users actually experience them. Experiences are categorized by:
-
the form factor of the users' devices
- desktop
- phone
- tablet
-
users' effective connection type (ECT) in mobile terms
- offline
- slow 2G
- 2G
- 3G
- 4G
- users' geographic location
Experiences are measured monthly including paint, load, and interactivity metrics. The first metric we'll look at is First Contentful Paint (FCP). This is the time users spend waiting for the page to display something useful to the screen, like an image or text. Next, we'll look at look at a loading metric, Time to First Byte (TTFB). This is a measure of how long the web page took from the time of the user's navigation until they received the first byte of the response. And finally, the last field metric we'll look at is First Input Delay (FID). This is a relatively new metric and one that represents parts of the UX other than loading performance. It measures the time from a user's first interaction with a page's UI until the time the browser's main thread is ready to process the event.
So let's dive in and see what kind of insights we can find.
FCP
In Figure 1 above you can see how FCP experiences are distributed across the web. Out of the millions of websites in the CrUX dataset, this chart compresses the distribution down to 1,000 websites where each vertical slice represents a single website. The chart is sorted by the percent of fast FCP experiences, which are those occurring in less than 1 second. Slow experiences occur in 2.5 seconds or more, and average experiences are everything in between. At the extremes of the chart, there are some websites with almost 100% fast experiences and some websites with almost 100% slow experiences. In between, websites have a combination of fast, average, and slow performance that seems to lean more towards fast or average than slow, which is good.
In order to categorize whether a website is sufficiently fast we will use the PageSpeed Insights (PSI) methodology where at least 90% of the website's FCP experiences must be faster than 1 second. Similarly a sufficiently slow website has 10% or more FCP experiences slower than 2.5 seconds. We say a website has average performance when it doesn't meet either of these conditions.
In Figures 2 and 3, the results show that only 2.17% of websites are considered fast while 60.28% of websites are considered slow. To help us understand how users experience FCP across different devices, let's segment by form factor.
FCP by device
In Figures 4 and 5 above, the FCP distributions of 1,000 sample websites are broken down by desktop and phone. It's subtle, but the torso of the desktop fast FCP distribution appears to be more convex than the distribution for phone users. This visual approximation suggests that desktop users experience a higher overall proportion of fast FCP. To verify this we can apply the PSI methodology to each distribution.
According to PSI's classification, 2.80% of websites have fast FCP experiences overall for desktop users, compared to 1.76% for mobile users. The entire distribution is skewed slightly faster for desktop experiences, with fewer slow websites and more in the fast and average category.
FCP by ECT
In Figures 8 and 9 above, FCP experiences are grouped by the ECT of the user experience. Interestingly, there is a correlation between ECT speed and the percent of websites serving fast FCP. As the ECT speeds decrease, the proportion of fast experiences approaches zero. 8.44% of websites serve fast FCP to users with 4G ECT while 57.59% of those websites serve slow FCP. 96.49% of websites serve slow FCP to users with 3G ECT, 99.68% to 2G ECT, and 99.89% to slow-2G ECT. These results suggest that websites almost never serve fast FCP consistently to users on slow connections.
FCP by geo
Finally, we can slice FCP by users' geography (geo). The chart above shows the top 23 geos having the highest number of distinct websites, an indicator of overall popularity of the open web. The geos are sorted by their percent of websites having sufficiently fast FCP experiences. At the top of the list are three Asia-Pacific (APAC) geos: Korea, Taiwan, and Japan. This could be explained by the availability of extremely fast network connection speeds in these regions. Korea has 11.10% of websites meeting the fast FCP bar and only 28.00% rated as slow FCP. Recall that the global distribution of fast/average/slow websites is approximately 2/38/60, making Korea a significantly positive outlier.
Other APAC geos tell a different story. Thailand, Vietnam, Indonesia, and India all have fewer than 1% of fast websites. These geos also have more than double the proportion of slow websites than Korea.
TTFB
Time to First Byte (TTFB) is a measure of how long the web page took from the time of the user's navigation until they received the first byte of the response.
To help explain TTFB and the many factors that affect it, let's borrow a
diagram from the Navigation Timing API spec. In Figure 11 above, TTFB is
the duration from startTime
to responseStart
,
including everything in between: unload
,
redirects
, AppCache
, DNS
,
SSL
, TCP
, and the time the server spends
handling the request. Given that context, let's see how users are
experiencing this metric.
Similar to the previous FCP chart, this is a view of 1,000 representative samples ordered by fast TTFB. A fast TTFB is one that happens in under 0.2 seconds (200 ms), a slow TTFB happens in 1 second or more, and everything in between is average.
Looking at the curve of the fast proportions, the shape is quite different from that of FCP. There are very few websites that have a fast TTFB greater than 75%, while more than half are below 25%.
Let's apply a TTFB speed label to each website, similar to the PSI methodology used above for FCP. If a website serves fast TTFB to 90% or more user experiences, it's labelled as fast. Otherwise if it serves slow TTFB to 10% or more user experiences, it's slow. If neither of those conditions apply, it's average.
69.20% of websites have slow TTFB. This is significant because TTFB is a blocker for all other performance metrics to follow. A user cannot possibly experience a fast FCP if the TTFB takes more than 1 second. Recall from the previous FCP section that about 98% of websites do not have fast FCP. Therefore the ~70% of websites that have slow TTFB are completely ineligible to be considered as having fast FCP.
TTFB by geo
Now let's look at the percent of websites serving fast TTFB to users in different geos. APAC geos like Korea, Taiwan, and Japan are still outperforming users from the rest of the world. But no geo has more than 3% of websites with fast TTFB.
FID
The last field metric we'll look at is First Input Delay (FID). This metric represents the time from a user's first interaction with a page's UI until the time the browser's main thread is ready to process the event. Note that this doesn't include the time applications spend actually handling the input. At worst, slow FID results in a page that appears unresponsive and a frustrating user experience.
Let's start by defining some thresholds. According to the PSI methodology, a fast FID is one that happens in less than 50 ms. This gives the application enough time to handle the input event and provide feedback to the user in a time that feels instantaneous. A slow FID is one that happens in 250 ms or more. Everything in between is average.
You know the drill by now. This chart shows the distribution of 1,000 websites' fast, average, and slow FID. This is a dramatically different chart from the ones for FCP and TTFB. The curve of fast FID very slowly descends from 100% to 75% then takes a nosedive. The overwhelming majority of FID experiences are fast for most websites.
The PSI methodology for labelling a website as having sufficiently fast or slow FID is slightly different than that of FCP. For a site to be fast, 95% of its FID experiences must be fast. A site is slow if 5% of its FID experiences are slow.
The distribution of fast, average, and slow websites appears to be more balanced, with 26.61% of websites qualifying as fast and 31.35% as slow.
FID by device
Breaking FID down by device, it becomes clear that there are two very different stories. Desktop users enjoy fast FID almost all the time. Sure there are some websites that throw out a slow experience now and then, but the results are predominantly fast. Mobile users, on the other hand, have what seem to be one of two experiences: pretty fast (but not quite as often as desktop) and almost never fast. The latter is experienced by users on only the tail ~10% of websites, but this is still a substantial difference.
When we apply the PSI labelling to desktop and phone experiences, the distinction becomes crystal clear. 70.32% of websites' FID experienced by desktop users are fast compared to 6.48% slow. For mobile experiences, 13.76% of websites are fast while 43.03% are slow.
FID by ECT
On its face, FID seems like it would be driven primarily by CPU speed. It'd be reasonable to assume that the slower the device itself is, the higher the likelihood that it will be busy when the user attempts to interact with a web page, right?
The ECT results above seem to suggest a correlation between connection speed and FID performance. As users' effective connection speed decreases, the percent of websites on which they experience fast FID also decreases and slow FID increases. Interestingly, the percent of websites with average FID is about the same across ECTs.
FID by geo
In this breakdown of FID by geographic location, Korea is out in front of everyone else again. But the top geos have some new faces: the US, Australia, and Canada are next with 35-40% of websites having fast FID.
As with the other geo-specific results, there are so many possible factors that could be contributing to the user experience. For example, perhaps wealthier geos are more privileged to be able to spend more money on better network infrastructure and its residents have more money to spend on desktops and/or high-end mobile phones.
Conclusion
Quantifying how fast a web page loads is an imperfect science that can't
be represented by a single metric. Conventional metrics like
onload
can miss the mark entirely by measuring irrelevant
or imperceptible parts of the user experience. User-perceived metrics
like FCP and FID more faithfully convey what users see and feel. Even
still, neither metric can be looked at in isolation to draw conclusions
about whether the overall page load experience was fast or slow. Only by
looking at many metrics holistically can we start to understand the
performance for an individual website and the state of the web.
The data presented in this chapter showed that there is still a lot of work to do to meet the goals set for fast websites. Certain form factors, effective connection types, and geos do correlate with better user experiences, but we can't forget about the combinations of demographics with poor performance. In many cases, the web platform is used for business; making more money from improving conversion rates can be a huge motivator for speeding up a website. Ultimately, for all websites, performance is about delivering positive experiences to users in a way that doesn't impede, frustrate, or enrage them.
As the web gets another year older and our ability to measure how users experience it improves incrementally, I'm looking forward to developers having access to metrics that capture more of the holistic experience. FCP is very early on the timeline of showing useful content to users and newer metrics like Largest Contentful Paint (LCP) are emerging to improve our visibility into how page loads are perceived. The Layout Instability API has also given us a novel glimpse into the frustration users experience beyond page load. Equipped with these new metrics, the web in 2020 will become even more transparent, better understood, and give developers an advantage to make more meaningful progress to improve performance and contribute to positive user experiences.


We exchange blockchain!
- leverage intuitive experiences
- transform granular deliverables
- e-enable killer partnerships
- matrix seamless methodologies
- envisioneer integrated supply-chains
- syndicate compelling ROI
- utilize proactive bandwidth
- engage cross-platform web services
- streamline open-source interfaces
- embrace end-to-end functionalities
- synthesize web-enabled partnerships
- reinvent bricks-and-clicks relationships
- enable bricks-and-clicks infomediaries


Daily Meals
Calories : {{ daily.calories }}
Breakfast
{% for meal in daily.breakfast %}
- {{meal.name}} : {{meal.calories}} calories
{% endfor %}
Lunch
{% for meal in daily.lunch %}
- {{meal.name}} : {{meal.calories}} calories
{% endfor %}
Dinner
{% for meal in daily.dinner %}
- {{meal.name}} : {{meal.calories}} calories
{% endfor %}
My plans
{% for plan in plans %}
Name: {{ plan.name }} - Calories: {{ plan.goal }} calories
{% endfor %}


If you can read this, then you've successfully passed the Basic Auth for the Serverless Static Website with Basic Auth.
Most likely, you've used the demo username guest
and password letmein
.
This website is part of a GitHub repository.


Dear Community,
We are writing to let you know about a security incident we recently identified and addressed involving a subset of user data.
We know transparency is important to our community, and we want to share with you what we have learned from our investigation,
measures we have taken, as well as steps you can take.
What happened
We recently identified unauthorized access to some of our databases.
In response to this discovery, we immediately launched an investigation.
Findings from the investigation indicate an unauthorized person accessed and potentially obtained data.
What information was involved
The databases involved may have contained email address.
No passwords were taken since we don't use passwords.
What we are doing
As a precaution, we have expires all users’ tokens.
What you can do
You can continue to use JWT without further action. However, next time you log into your account, you will need to apply for another login token.
The details on how to do this are:
1.
2.
3.
Where to find more information and updates
We deeply regret this incident happened. For more information and answers to frequently asked questions,
we have created a support page with more details about the incident.
Sincerely,
The JWT team


Welcome Caterer Sanni
Summary
Orders 100
Customers 50
Inventory Sold 90%
Total Sales ₦100000
Order List
Click Order Id To View Details
Id |
Status |
Total Amount |
|
112345-1 |
Delivered |
₦1000 |
|
112345-2 |
Delivered |
₦1000 |
|
112345-3 |
Delivered |
₦1000 |


Plugin Information |
|---|
No information for the plugin 'externalresource-dispatcher' is available. It may have been removed from distribution. |
This plugin adds support for external resources in Jenkins. An external resource is something external
attached to a Jenkins slave and can be locked by a build, which thus gets exclusive access to it, then released after the
build is done. Examples of external resources are phones, printers and USB christmas trees.
Note that even though the 'b' fell off in the latest release, this plugin is still considered to be in beta stage.
Quick usage guide
- Connect an external resource of some kind to a Jenkins node.
- Create Metadata on the node for the ExternalResource.
- Create a project in Jenkins. Click the Resource Selection Criteria check box and add a name-value pair that matches your ExternalResource.
- Start a build of the project. Note on the node page that the external resource is locked to your build.
- Start another build using the same selection criteria. Note that this build will wait for the first one to finish, due to no free resource.
Adding ExternalResources to a node
Configure the node and click the Metadata check box. Add an ExternalResourceTreeNode with an ExternalResource as a child.
An ExternalResourceTreeNode is a collection of ExternalResource objects and the only Metadata type that can contain ExternalResource objects.
Fill in Name, Id and Description and add any amount of other Metadata for the resource.
The External Resource metadata for a node.
Selection criteria
In any project, selection criteria can be added using the check box named "Resource Selection Criteria".
When the project is built, the plugin tries to find a slave among the slaves to run on (selected as usual via a label)
that matches the selection criteria. It does this by matching metadata values on the external resource defined
on the slave. If the plugin finds a match, it locks the resource to the build and starts the build on the matched slave.
Once the build finishes, the resource is unlocked. Multiple selection criteria can be added, the current "Simple Selection"
adds an implicit "and" between the criteria, so that all the criteria must be matched. We plan to add a more advanced
resource selection in the future.
Currently, only one selector type exists, the StringResourceSelection. This is extendable, so plugin developers
can add their own. The String selection criteria tries to match a String value to a metadata value exactly.
Selection criteria.
Locked resource
For a build with a locked resource, we expose all the properties of the resource as environment variables, with the names:
MD_EXTERNAL_RESOURCES_LOCKED_NAME_OF_THE_PROPERTY_IN_CAPS. These can be used to refer to the locked resource from build steps.
Administrator settings
To add ExternalResources to a node, write permission to the node is needed. The same goes for adding resource selection
on a project, i.e. write permission to projects is needed.
On the configure system page in Jenkins, under External Resource Dispatcher Configuration, a couple of new settings are available:
- Release Key - not used yet, will be used for a "Release All" feature where all resources on a node can be released by clicking a button.
- Reservation Time - the number of seconds to reserve an ExternalResource. Since we use a QueueTaskDispatcher, we can't say for sure that
a build will run on a particular machine, so we reserve the resource and then lock it once it starts to run. - External Resource Manager - described in detail further down, this sets the default manager for the Jenkins master.
- Admin Notifier File - the path to a file in which to log problems with the resource handling.
Under the hood
Here we describe the different parts of the plugin in greater detail, with more focus on implementation details.
Dependency to Metadata plugin
This plugin has a dependency to the Metadata plugin and won't run without it. We use new Metadata types (ExternalResource and ExternalResourceTreeNode)
to describe the external resources on the nodes.
External Resource Metadata
We have added two new Metadata types, ExternalResource and ExternalResourceTreeNode. Only an ExternalResourceTreeNode can contain ExternalResources.
ExternalResource
An external resource is based on a TreeNodeMetadataValue, so it can contain other MetadataValues as children.
Other than those, it should always contain the following properties:
- Name - the name of the resource.
- Id - a unique identifier for the resource.
- Description - text describing the resource.
- Enabled - true if the resource is up and running, ready to be used, false if not.
ExternalResourceTreeNode
This is also based on TreeNodeMetadataValue, but can only contain ExternalResources as children.
It is also the only type of node that can contain ExternalResources. The reason for this is the resource handling.
In addition to its children, an ExternalResourceTreeNode contains an ExternalResourceManager. All the children of the ExternalResourceTreeNode will use the same manager.
ExternalResourceManagers
An ExternalResourceManager is what takes care of the resource handling. It is responsible for locking and releasing the
resources. Currently, two manager types exist, NoopExternalResourceManager and ResourceMonitorExternalResourceManager.
Plugin developers can add their own managers.
NoopExternalResourceManager
The easiest way of getting up and running with the External Resource Dispatcher. The NoopExternalResourceManager takes
care of the resource handling all from within Jenkins. If other systems outside of Jenkins are using the same External
Resources, this manager should not be chosen since the locking/releasing of resources will not look outside Jenkins.
ResourceMonitorExternalResourceManager
The difference between the NoopExternalResourceManager and this one is that the ResourceMonitor expects something external to Jenkins
to take care of the resources, and communicates with the plugin through CLI or http requests. At Sony, we have a service running on the slave machines
that can communicate with the ResourceMonitorExternalResourceManager which handles the locking and releasing of our Android phones.
When a phone is connected via usb to a slave computer, it also automatically adds it to Jenkins via http.
The service will hopefully soon be released as open source as well.
Command Line Interface (CLI) and HTTP
There are some CLI and HTTP commands intended primarily to be used by an ExternalResourceManager but can be used by a human or other system as well.
Most of the commands give a response in JSON format for example
{type: "OK", errorCode: 0, message: "OK"}
for an ok response.
All HTTP commands are placed under http://yourjenkins/external-resource-httpcli
Below is a brief description of each command, you can look in the Jenkins CLI help for information about their parameters.
disable-external-resource
HTTP name: /disable
Disables a resource on the slave. The resource can no longer be booked by jobs until it is enabled again.
Requires that the user has the EnableDisable permission set for the node that the resource is on.
enable-external-resource
HTTP name: /enable
Enables a previously disabled resource.
Requires that the user has the EnableDisable permission set for the node that the resource is on.
expire-external-resource
HTTP name: /expireReservation
Expires the lease of a reserved resource making it available again to be used by a build. The build that reserved it in the first place will probably fail when it starts and tries to lock the resource.
lock-external-resource
HTTP name: /lockResource
Adds the lock information to the resource so that no build can use it untill it is released. This is to inform Jenkins that another external process has locked it instead of a Jenkins build.
Requires that the user has the LockRelease permission set for the node that the resource is on.
reserve-external-resource
HTTP name: /reserveResource
Similar to the lock but for the reserve info instead.
Requires that the user has the LockRelease permission set for the node that the resource is on.
release-external-resource
HTTP name: /releaseResource
Removes any lock and reservation from the resource making it available again for builds to grab.
Requires that the user has the LockRelease permission set for the node that the resource is on.
Integration with the Build Flow Plugin
There is an extension point for Build Flow Plugin that can be used for easy access to the resource manager from within the build flow script like:
def manager = extension.'externalresource-dispatcher' manager.lock(...)
Change Log
Version 1.0b (released Nov 22, 2012)
Initial beta release
Attachments:
dispatcher-selection.png (image/png)
dispatcher-selection.png (image/png)


Preparation time
less than 30 mins
Cooking time
no cooking required
Serves
Makes 12
Dietary
Don't want to spend all your money on snack bars? Just throw a few ingredients into your food processor and voila!
Grease and line a 20x20cm/8x8in baking tray.
Put all the ingredients into a food processor and blend until the cashew nuts become tiny pieces.
Remove the lid and add 1 tablespoon of water and blend again. If the mixture is not already sticking together, add another spoon of water and blend again. Repeat until the mixture starts to stick together.
Using a spoon or spatula, transfer the mixture into the lined tray. Press the mixture into the tin and put in the fridge to set for at least an hour.
Remove from the fridge and slice into 12 bars or smaller chunks. Wrap individually in greaseproof paper and keep in the fridge until you need a healthy snack on the go.